On Monday, 1 April 2013 at 22:46:49 UTC, Ali Çehreli wrote:
On 04/01/2013 02:01 PM, Dmitry Olshansky wrote:> 02-Apr-2013
00:34, Ali Çehreli пишет:
>> The failed assertion may be the moment when the program
detects that
>> something is wrong. A safe program should stop doing
anything else.
>
> And that's precisely the interesting moment. It should stop
but the
> definition of "stop" really depends on many factors. Just
pretending
> that calling abort is a panacea is totally wrong IMO.
>
> BTW what do you exactly mean by "safe" program?
I meant a program that wants to produce correct results. I was
indeed thinking about Therac-25 that Simen Kjærås mentioned. I
agree that there must be hardware fail-safe switches as well
but they could not protect people from every kind of software
failure in that example.
Having said that, I can see the counter argument as well: We
are in an inconsistent state, so trying to do something about
it could be better than not running a cleanup code. But I also
remember that an AssertError may be thrown by an assert() call,
telling us that a programmer put it in there explicitly,
meaning that the program cannot continue. If there was any
chance of recovery, then the programmer could have thrown an
Exception or remedy the situation right then.
Yes, this is definitively a per case issue.
Not running cleanup code can transform a small issue in a big
disaster as running can make the problem worse.
I don't think wiring in the language the fact that error don't
run the cleanup code is rather dangerous.
If I had to propose something, it would be to handle error the
same way exception are handled, but propose a callback that is
ran before the error is throw, in order to allow for complete
program stop based on user logic.
