DIP33: A standard exception hierarchy

[Jonathan M Davis]

On Friday, April 05, 2013 15:42:00 deadalnix wrote:
> 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.

Part of the point is that if you had an Error, there _is_ no graceful 
shutdown. It's in an invalid state. Doing _anything_ at that point is risky. 
Depending on why the Error occurred, you could just as easily completely 
corrupt playlist files as properly update them. If you have an Error, you 
basically just crashed. Don't expect that to be any cleaner than if someone 
just pulled the plug on your computer.

The fact that an Error is thrown rather than the program simply aborting gives 
you some chance of saving your program in circumstances where you actually 
know that catching the Error and continuing can work (e.g. in rare 
circumstances, that might work with OutOfMemoryError), and it gives you the 
chance tot attempt some truly critical clean-up code if you want to, but 
again, you can _never_ rely on clean-up happening correctly 100% of the time 
no matter what the language does, because your program could be forcibly 
killed by kill -9 or by power loss or whatever. So, if there's anything that 
you need to do in order to guarantee that your program always has consistent 
state, don't even rely on Exceptions for that. It won't always work.

Errors should be extremely rare. It's not like you just had bad input. If an 
Error occurs, something seriously wrong happened in your program. It could be 
a programming bug that you never caught, or it could be that you have data 
corruption or that your hardware is actually busted and doing the wrong thing. 
You can't know what's going wrong, so you can't know how safe it is to attempt 
clean-up code. Maybe it is, maybe it isn't. It's basically the same as if your 
computer outrigt crashed. And do you really expect that to go cleanly?

All the programs that I use that have playlists and the like return to a 
previously valid state when they crash or are killed - either by updating 
their state as they go along and making sure that they do so in a way that the 
playlist is valid and/or by restoring to the state that they were in when the 
program last shutdown correctly. Neither of those require that Errors be 
handled. Rather, they require making updates after successful operations. It's 
then pretty much irrelevant if future operations go horribly wrong. When you 
start the program up again, it'll simply put itself back in the last known 
good state.

- Jonathan M Davis