On 6/1/2012 1:48 AM, Dmitry Olshansky wrote:
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.
Except that you do not know why the arithmetic turned out wrong - it could be
the result of memory corruption.
@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.
You do have the option of catching assert errors in D, but such cannot be
represented as a correct or robust way of doing things.
Wrong values don't always corrupt "the whole program" state.
Right, but since you cannot know how those values got corrupt, you cannot know
that the rest of the program is in a valid state. In fact, you reliably know
nothing about the state of a program after an assert fail.
It's too conservative point of view. It is a reasonable DEFAULT, not a rule.
It's a rule. Break it at your peril :-) I am not going to pretend that it is a
reasonable thing to do to try and keep running the program.
(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)
Other people writing crappy, unreliable software is no excuse for us.
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.
OOM is a special case. I agree that that isn't a corruption error. But I've
almost never seen a program that could recover from OOM, even if it was designed
to. (For one reason, the recovery logic for such is almost never tested, and so
when it is tripped, it fails.)
I don't agree that OutOfMemory is critical:
--> make it an exception ?
The reason it is made non-recoverable is so that pure functions can do something
useful.
