Catching a hot potato

[Gor Gyolchanyan]

Thanks for the detailed answer.
Example of when i would like to recover from a segfault:
I have different independent parts of an app, which MAY cooperate. If,
however, one of them crashes (e.g. they come from different sources)
the other one will continue to work but without the cooperation
functionality.

On Sat, Oct 15, 2011 at 2:58 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> 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
>