runtime hook for Crash on Error

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Jun 1 01:48:27 PDT 2012


On 01.06.2012 5:16, Walter Bright wrote:
> On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
>> On 31.05.2012 13:06, deadalnix wrote:
>>> 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.
>
> This is all based on the assumption that the program is still in a valid
> state after an assert fail, and so any code executed after that and the
> data it relies on is in a workable state.
>
 > This is a completely wrong assumption.

To be frank a "completely wrong assumption" is flat-out exaggeration. 
The only problem that can make it "completely wrong" is memory 
corruption. Others just depend on specifics of system, e.g. wrong 
arithmetic in medical software == critical, arithmetic bug in "refracted 
light color component" in say 3-D game is no problem, just log it and 
recover. Or better - save game and then crash gracefully.

Keep in mind both of the above are likely to be assert(smth), even 
though the last arguably shouldn't be it. But it is logic invariant check.

@safe D code should be enough to avoid memory corruption. So in @safe D 
code AssertError is not memory corruption. Being able to do some logging 
and gracefull teardown in this case would be awesome. I mean an OPTION 
to do so.

Wrong values don't always corrupt "the whole program" state. It's too 
conservative point of view. It is a reasonable DEFAULT, not a rule.

(just look at all these PHP websites, I'd love them to crash on critical 
errors yet they still crawl after cascade failures with their DBs, LOL)

BTW OutOfMemory is not an Error. To me it's like can't open file. Yeah, 
it could be critical if your app depends on this articular file but not 
in general.

To summarize:
I agree there are irrecoverable errors:
	-->call abort immediately.
I agree there are some I don't know if critical:
	--> call user hook to do some logging/attempt to save data, then abort
	or
	---> provide stack undiwinding
	 so that thing cleans it up itself (more dangerous)

I don't agree that OutOfMemory is critical:
	--> make it an exception ?



-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list