Exception slipping through the catch block?

[Neia Neutuladh]

On Thu, 08 Nov 2018 17:27:40 -0700, Jonathan M Davis wrote:
> You ran into one of the rare cases where it makes sense catch an Error
> or a Throwable, and you're one of the few people who understands the
> situation well enough to deal with it properly. The vast majority of D
> programmers don't. Certainly, anyone who has to ask about the
> differences between Throwable, Error, and Exception doesn't.

I really don't believe it's that rare or that fraught, most of the time.

If an error happens, it's better for most programs to try to leave behind 
enough artifacts for you to start debugging the problem. Most of the time, 
a stacktrace on stderr is good enough and still possible. And that's what 
the runtime does.

This isn't, strictly speaking, safe. Your program detected an error, and 
in Walter's book, that means you can't trust the program to do *anything*. 
Unwinding the stack, formatting a stacktrace, writing to stderr, this is 
all Dangerous Stuff You Shouldn't Be Doing. Even sending your process 
sigabrt to trigger a core dump is potentially dangerous.

But the utility is greater than the likely harm, which is why druntime 
will unwind the stack, format a stacktrace, and write to stderr when an 
Error is thrown and not caught.

Similarly, if your program logs to a file normally and you use that logfile 
for most of your debugging, it's sensible to try to log the error to that 
file and then exit. Especially if, like with H. S. Teoh's case, it's 
difficult or impossible for you to access the process's stderr.

This is still *slightly* fraught. If your logging system is responsible 
for that Error being thrown, you probably won't succeed in logging the 
Error. If you have custom Error classes that do weird things, those things 
are more likely to break. Your application might be out of memory, so the 
allocations involved in logging could also fail.

So, moderately fraught, but I don't think it's "here be dragons" any more 
than usual.