Exception slipping through the catch block?

[H. S. Teoh]

On Thu, Nov 08, 2018 at 01:28:47PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Thursday, November 8, 2018 10:55:45 AM MST Stanislav Blinov via 
> Digitalmars-d-learn wrote:
> > On Thursday, 8 November 2018 at 16:13:55 UTC, Mike Parker wrote:
[...]
> > > No, you should never catch Errors. They're separate for a
> > > reason.
> >
> > Never say never :) There are legitimate cases for catching an
> > Error or even a Throwable (for example, error propagation in a
> > multi-threaded environment). However, this is not one of such
> > cases.
> 
> Yeah, but basically, the rule of thumb is never. Errors are fatal
> error conditions which are supposed to terminate the program, and
> programs should not be trying to recover from them. No one should be
> attempting to catch them unless they know what they're doing, which
> honestly, probably isn't going to be very many people for something
> like this.

Recently I ran into a case where catching Throwable makes sense: I have
an Android application where the main code interfacing with the Android
OS is written in Java, but program logic is written in D, called via
JNI.  Since the JVM obviously cannot handle D exceptions, any unhandled
D exception that makes it past the JNI boundary would cause the
application to crash.  So what I did was to have the JNI interfacing
code (on the D side) catch *everything*, i.e., Throwable, marshall the
error message into a Java object, then send it via JNI back to the Java
code that then displays the error message before aborting the
application.  Extremely valuable in debugging, since otherwise I'd have
to extract the stacktrace from the system logs, which is a pain.


> Exceptions are for error conditions which are potentially recoverable.
> Program input or environmental state was bad (e.g. a missing file).
> They aren't necessarily indicative of bugs in the program, and the
> program can potentially recover from them and continue to function
> perfectly fine.
> 
> Errors on the other hand, are used to indicate actual bugs in the
> program or fatal conditions with resources which cannot be recovered
> from (e.g. the GC running out of memory). They are intended simply to
> be informative and not to be caught. The stack is not necessarily
> properly unwound when they are thrown. Full exception handling code is
> not necessarily even in place when they are thrown, and they can be
> thrown from nothrow code. By definition, your program is in an invalid
> state when you catch an Error, and catching an Error to do much of
> anything is dangerous.
[...]

Agreed in general.  In my case, though, being able to catch an Error
makes it possible to pass on the error message to the Java code and
displayed on the screen, instead of the whole thing crashing and burning
with no indication of what went wrong.


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.