DIP33: A standard exception hierarchy

[deadalnix]

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.