DIP33: A standard exception hierarchy

[deadalnix]

On Friday, 5 April 2013 at 01:11:40 UTC, Jonathan M Davis wrote:
> Well, the program has no way of knowing _why_ popFront is being 
> called on an
> empty range or an invalid index is being passed to opIndex or 
> opSlice. The
> fact that it happened is proof that either there's a 
> programming bug or that
> things are corrupted and who-knows-what is happening. In either 
> case, the
> program has no way of knowing whether it's safe to run the 
> clean-up code or
> not. It could be perfectly safe, or things could already be in 
> seriously bad
> shape, and running the clean-up code would make things worse 
> (possibly
> resulting in things like deleting the wrong file, depending on 
> what the clean-
> up code does and what went wrong).
>
> The problem is that while it's frequently safe to just run the 
> clean-up code,
> sometimes it's very much _not_ safe to run it (especially if 
> you get memory
> corruption in @system code or something like). And we have to 
> decide which
> risk is worse.
>
> And one good thing to remember is that Errors should be 
> _extremely_ rare. They
> should basically only happen in debug builds when you're 
> writing and debugging
> the program and in released code when things go horribly, 
> horribly wrong. And
> that would mean that it's far more likely that in production 
> code, Errors are
> normally being thrown in situations where doing clean-up is 
> likely to make
> things worse.
>
> Another good thing to remember is that there's _never_ any 
> guarantee that
> clean-up code wil actually run, because your program could be 
> forcibly killed
> in a way that you can't control or protect against (e.g. the 
> plug being
> pulled), so if your code truly relies on the clean-up code 
> running for it to
> work properly when it's restarted or leave your system in a 
> consistent state
> or anything like that, then you're pretty much screwed 
> regardless of whether
> clean-up is done on Errors.
>
> - Jonathan M Davis

Removing the plug a failure that is way more serious than an 
array out of bound access. Why do we want to worsen the array 
thing just because the later may happen ?

I guess that is the same logic that lead to theses cars we see in 
movies that explode each time something goes wrong. After all, 
the car is likely to be broken, so let's just let it explode.

Back on a more software related example. Let's consider a media 
player in which such error occurs (such software uses a lot of 
3rd party code to support many format, desktop integration, 
whatever). How to argue that the software must plain crash, and, 
by the way, the config and playlist are not saved, so you'll 
restart the soft playing random crap preferably at maximum volume 
in your headphones (bonus point if it is some porn in a public 
area), instead of simply displaying a graphical glitch, skip a 
frame, go to the next item in the playlist, or even quit while 
saving the playlist/config so it can be restarted and the user 
can resume its film ?

Right now, it isn't even possible to try a graceful shutdown when 
really, the program is unlikely to be in a completely 
unpredictable state, especially in @safe code.