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.
