DIP33: A standard exception hierarchy

[Jonathan M Davis]

On Thursday, April 04, 2013 23:50:25 deadalnix wrote:
> On Thursday, 4 April 2013 at 21:25:18 UTC, Jonathan M Davis wrote:
> > There are obviously exceptions to that (e.g. the in operator),
> > but as far as
> > indexing, slicing, and popFront go, it should be considered a
> > programming bug
> > if they're used on elements that aren't there.
> 
> It is where the current design choice make no sense.
> 
> If they are error, the recovery code isn't executed. Such
> operation don't put the program in an invalid state (in fact, it
> prevent the program to go in invalid state). In such situation,
> not running that recovery code is likely to transform a small
> error into a huge mess.
> 
> The case is very different from Ali's example before, where the
> wrong file can be deleted.

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