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.

On Fri, Nov 09, 2018 at 01:14:08AM +0000, Neia Neutuladh via Digitalmars-d-learn wrote: [...]
> 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.

If we wanted to be *completely* safe according to Walter's definition, we'd have to completely decouple Error handling from the process that reaches a `throw new Error(...)` (or any of its derived classes thereof).  You'd have a monitor running in a completely separate process from the main program, that regularly checks up on the health of the latter.  When the latter encounters an Error, it should immediately execute a 'hlt' instruction, or enter a 1-instruction empty infinite loop, and the monitor process (which, presumably, has not had its logic compromised) would detect this and kill / restart / extract core dump info from the failed process.

Anything inside the failed process itself would not be trustworthy. (Conceivably, for example, a remote attacker may have triggered a buffer overflow that overwrote, say, the variables holding the file descriptors for the logfile, so as to redirect any logged messages to a publicly-readable place, and may have further corrupted the logging module's state so that instead of writing the stacktrace or error message to the file, it writes the contents of /etc/passwd or some such sensitive file instead. All bets are off once an assertion fails.  Or worse yet, the assertion failure may have been caused by some internal code gone wrong that has overwritten some critical function pointers so that calling a dynamically-linked druntime function accidentally ends up invoking the function to increase laser output intensity 100x instead, thereby killing the patient undergoing surgery by the machine controlled by the code.)


> 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.

Yes, the utility outweighs the potential dangers, especially during development when you want maximum information about what went wrong, so it makes sense to catch Errors for that purpose.

Catching Errors and then continuing to execute application logic as if nothing happened, though, is a big no-no.


T

-- 
Caffeine underflow. Brain dumped.