Catching a hot potato

[Jonathan M Davis]

On Saturday, October 15, 2011 14:29:04 Gor Gyolchanyan wrote:
> The other day i was re-reading the std.exception docs and stumbled
> upon "It's ill-advised to catch anything, that is not Exception or
> derived from it".
> Can you show me examples when catching a Throwable is a good idea?
> Also, i had some thoughts about catching AcessViolation exception in a
> modular application to avoid my app crashing when a module crashes,
> but i was told, that segfaults indicate a messed up memory and nothing
> is guaranteed to work after a segfault.
> My question is, is it true, that segfault means THE END, and if so,
> what's the point in allowing to catch it?
> Also, how do i prevent DLLs from crashing my process like that?

A prime example of catching an Error being useful would be catching an 
AssertError in unit tests. It's fairly rare that it's useful, but if you want 
to test that an assertion was triggered like it was supposed to (or if you 
want to trigger a unit testing function such as assertThrown), then you're 
going to have to catch an AssertError. But since in such cases, you're 
generally dealing with very localized code, you know that it's not going to 
cause major stability issues.

Another case where you might want to catch an Error would be if you have code 
where you know that you can reliably catch an OutOfMemoryError and do 
something to release memory, but that would certainly be an abnormal 
situation.

The reason that catching non-Exceptions is problematic (besides the fact that 
Errors generally indicate conditions which you can't really recover from) is 
that destructors, scope statements, and finally blocks are all skipped for 
Throwables which aren't Exceptions, so if they're thrown, your program will 
very quickly end up in an invalid state. You can only safely catch them in 
code where you're in control of what it's doing and can be sure that the 
program's state hasn't been compromised by the Error being thrown. But that's 
quite rare.

I suppose that the big thing is that D is a system's programming language and 
so it tries to make it possible to do low-level and/or dangerous stuff when you 
actually need to. So, while catching Errors is generally not a good idea, in 
there rare case where it _is_ a good idea and you can verify that it's going 
to work, you can do it. But precisely because it's so rarely a good idea, it 
_is_ a bit hard to come up with good cases where you'd do it. Catching 
AssertErrors in unit tests is the only case where I've personally done it.

Oh, and you can't catch segfaults anyway. They aren't exceptions. They're 
signals. You need to register a signal handler to handle them, and I'd argue 
that it's _never_ a good idea to try and recover from a segfault. Best case, 
you try and shut your program down a bit more gracefully than just crashing 
(and maybe cause it to be started again if you need to, but certainly _not_ 
try and make it recover without restarting it).

- Jonathan M Davis