Re: Try/Catch

new topic     » goto parent     » topic index » view thread      » older message » newer message
Spock said...
mattlewis said...
Spock said...

If the error code is ORed instead of MOVed then explicit handling is not required at each step. It will simply "bubble up" until it encounters a test written for it. Whole levels could be written without any error checking but the error code will still happily pass through.

But I don't want it to "happily pass through." I want it to get to the error handling code immediately, which is what try/catch does.

Matt

More or less, yes. Some calls will force the user to check errno immediately afterwards.

How? What's to stop a program from just refusing to check errno at all, e.g. to not even bother to assign the return value of open() to anything?

Spock said...

The program could return at that point or handle the error then and there

So something in the interpreter checks that immediately following the statement that causes the error, there's another statement accessing errno, and if it doesn't do that then we get an ex.err style crash?

This is a lot better.

Spock said...

(or somewhere else in that routine).

This is less better. If we're waiting for the routine to return before generating the ex.err crash, there's still a chance for a cascade of 'returnable' errors.

Also, what if we get an error in top-level code?

Spock said...

Errors from other calls won't immediately affect the program operation.

How do we know which is which? What should be returnable and what shouldn't?

Spock said...

A cascade of errors is unlikely or would be very limited. In any case, an error log recording each error is kept for later study so we don't accidentally overwrite a previous error.

What goes into the error log and how do we access it? I guess we're saying that if the program ends and errno hasn't been cleared, we write out all the errors into ex.err, one by one, giving full filename and line information and call stack trace for each?

Spock said...

SSC might not be "better" than try/catch but is it materially worse?

If the requirement that the next statement immediately handle errno is followed,then the only bit that's worse is that it's a little onerous to have to deal with errors by adding checks on virtually every other statement.

If the requirement is just that the routine has to handle it before it returns, then we still have a chance for a cascade of errors that's higher than try/catch.

Spock said...

In some ways it might be simpler to implement.

Ironically, I think the easiest way to implement this concept is to use try/catch under the hood.....

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu