runtime hook for Crash on Error

Dmitry Olshansky dmitry.olsh at gmail.com
Thu May 31 03:22:01 PDT 2012


On 31.05.2012 13:06, deadalnix wrote:
> Le 31/05/2012 04:17, Walter Bright a écrit :
>> On 5/30/2012 8:05 AM, Steven Schveighoffer wrote:
>>> I'd classify errors/exceptions into three categories:
>>>
>>> 1. corruption/segfault -- not recoverable under any reasonable
>>> circumstances.
>>> Special cases exist (such as a custom paging mechanism).
>>> 2. program invariant errors (i.e. assert errors) -- Recovery is not
>>> defined by
>>> the runtime, so you must do it manually. Any decision the runtime
>>> makes will be
>>> arbitrary, and could be wrong.
>>> 3. try/catch exceptions -- these are planned for and *expected* to
>>> occur because
>>> the program cannot control it's environment. e.g. EOF when none was
>>> expected.
>>
>>
>> A recoverable exception is NOT a logic bug in your program, which is why
>> it is recoverable.
>>
>> If there is recovery possible from a particular assert error, then you
>> are using asserts incorrectly. Assert errors occur because your program
>> has entered an unanticipated, invalid state. There's no such thing as
>> knowing how to put it back into a valid state, because you don't know
>> where it went wrong and how much is corrupted, etc.
>
> A failure in database component should prevent me from close a network
> connection properly in an unrelated part of the program.
>
> This is called failing gracefully. And this highly recommended, and you
> KNOW that the system will fail at some point.

Exactly. + The point I tried to argue but it was apparently lost:
doing stack unwinding and cleanup on most Errors (some Errors like stack 
overflow might not recoverable) is the best thing to do.

Because crashing is easy ( hek catch(Error) abort(42); ), but not 
calling scope/destructors lays awful burden on programmer to do graceful 
clean up. The it's granted that nobody will ever bother doing it.

The fun boys of "crush immediately" should just call special runtime hook:
crashOnError(true);

Or the make it the default, but do _allow_ proper stack unwinding (= 
usual cleanup) after call to crashOnError(false).


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list