Disallow catch without parameter ("LastCatch")

Christopher Wright dhasenan at gmail.com
Mon Oct 26 21:15:55 PDT 2009


grauzone wrote:
> Christopher Wright wrote:

Please keep full attributions.

>>> PS: I wonder, should the runtime really execute finally blocks if an 
>>> "Error" exception is thrown? (Errors are for runtime errors, 
>>> Exception for normal exceptions.) Isn't it dangerous to execute 
>>> arbitrary user code in presence of what is basically an internal error?
>>
>> Are all Errors unrecoverable except by immediately aborting the 
>> application?
>>
>> What about logging?
>>
>> What about putting up a reasonable error message for the user?
>>
>> What about restarting the failed module in case the issue was 
>> temporary and environmental?
> 
> Something is wrong with your program internally if something like this 
> happens. You can't expect a consistent program state. And most of the 
> code in finally blocks was not written for such situations. You'll 
> probably end up throwing another runtime error from within a finally block.

Quite possibly. But immediately terminating the process is simply not 
acceptable. How am I going to fix this problem if I can't even log that 
a problem occurred? If I have a SaaS application, I have to rely on my 
users to email or call up to find out something bad happened?

What if it's an assertion error or a bounds error in a plugin? I can 
unload that plugin and continue on with no issues.

I'm getting OutOfMemoryErrors? I'll disable caching and prefetching and 
reduce my memory footprint by 80%. Problem solved.

There is one category of errors that is not recoverable. If the runtime 
is left in an inconsistent state, it should try to output an error 
message and terminate. Everything else, an application could potentially 
handle.



More information about the Digitalmars-d mailing list