Exception slipping through the catch block?

[H. S. Teoh]

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.