On 01/06/12 12:26, Walter Bright wrote:
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.
This argument seems to be:
1. There exist cases where you cannot know why the assert failed.
2. Therefore you never know why an assert failed.
3. Therefore it is not safe to unwind the stack from a nothrow function.
Spot the fallacies.
The fallacy in moving from 2 to 3 is more serious than the one from 1 to
2: this argument is not in any way dependent on the assert occuring in a
nothrow function. Rather, it's an argument for not having AssertError at
all.
