Re: Try/Catch

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

"What we need is a compelling argument for why recovery should be an option after a Throwable is thrown"

OR

"What we need is a compelling argument for why recovery should be an option after an unrecoverable occurs"

I think the answer to the former is self-evident. I don't think a compelling argument for the later exists, as the situation is by definition not recoverable. But the latter also has nothing to do with dcuny's original example and use case which lead him to ask about adding try/catch in the first place!

But what's the difference between a recoverable and unrecoverable?

You can trap the former and continuie program execution without making the sytem unstable or introducing logic errors (at least in principle), but you can't do this for the latter.

mattlewis said...

What about a bad subscript in a function?

This was dcuny's original example, IIUC. That's obviously recoverable (skip the operation and fall back to the caller so it can give the user of the editor a chance to save his or her data, or something).

mattlewis said...

Calling routine_id -1?

This can be made recoverable. In fact, we could make this have error handling akin to open() - if something went wrong, signal the caller and let the caller deal with it instead of crashing.

mattlewis said...

Again, anything that would normally call RTFatal could potentially be recoverable in one circumstance or another.

Actually, this is the problem - most of the "errors" that trigger RTFatal are often trivially recoverable - it was just RobCraig's decision to make them fatal errors.

mattlewis said...

This doesn't stop you from a fast fail development, either, assuming you watch / log these and fix them as you find them.

Agreed. But supporting try/catch doesn't stop someone from using fail fast development. Just leave out the catches while code is under development/unit testing/etc and then add them in before going into production.

Or, depending on your use case and personal preference, just don't use try/catch at all. It's not like we're turning into Java, where try/catches are required for use in ordinary, everyday events...

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

Search



Quick Links

User menu

Not signed in.

Misc Menu