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
