Catching Throwable

[Scott Harper]

I got bit by the NoClassDefFoundError. Lo and behold, I figured out what the
problem was, so thankfully that's not the question here...

This occurs in a servlet. In my doPost method, as a last resort, I was
catching (Exception e) just to make sure anything unexpected didn't go
un-noticed. What was throwing me off was that my last-chance catch block
never got executed to alert me of the problem. I wasn't getting any error
messages, but things just weren't working.

Alas, NoClassDefFoundError is not and Exception. By changing my last-chance
catch block to catch (Throwable) instead, I now get notified of the error.

As a relative newcomer to the Java language, is it considered good form to
catch Throwable?


scott

 

[alexandre_paterson]

I got bit by the NoClassDefFoundError. Lo and behold, I figured out what the
problem was, so thankfully that's not the question here...

This occurs in a servlet. In my doPost method, as a last resort, I was
catching (Exception e) just to make sure anything unexpected didn't go
un-noticed. What was throwing me off was that my last-chance catch block
never got executed to alert me of the problem. I wasn't getting any error
messages, but things just weren't working.

Alas, NoClassDefFoundError is not and Exception. By changing my last-chance
catch block to catch (Throwable) instead, I now get notified of the error.

As a relative newcomer to the Java language, is it considered good form to
catch Throwable?

No... It is usually considered bad form.

But what kind of Error do you plan to catch this way?

If it's only to catch NoClassDefFoundError, then not only it won't
work all the time and moreover there's a better alternative, clearly
explained in Joshua Bloch and Neal Gafter's
"Java Puzzlers" book. Puzzle 44: "Cutting Class".

A small excerpt:

"In summary, *do not depend on catching NoClassDefFoundError.
"The language specification carefully describes when class
"initialization occurs [JLS 12.4.1], but class loading is far less
"predictable. More generally, *it is rarely appropriate to catch
"Error or its subclasses*. These exceptions are reserved for
"failures from which recovery is not feasible.

A NoClassDefFoundError can be worked around by using
reflection and catching a ClassNotFoundException (which, as
it names implies, is not an Error).

So remember that catching Throwable will not even catch
all NoClassDefFoundError.

That said I still sometimes "catch" Throwable using:

Thread.setDefaultUncaughtExceptionHandler(
new Thread.UncaughtExceptionHandler() {
public void uncaughtException(
final Thread t, final Throwable e) {

to do some special kind of logging should "the shit hit the fan"
(eg when a 3rd party API which we're forced to use exhibits
some strange behaviour

Hope it helps a little bit,

Alex

 

[Scott Harper]

No... It is usually considered bad form.

But what kind of Error do you plan to catch this way?

Well that's just it, I don't know. But in this specific case just having an
indication that an error occurred would have saved me some time. This was
also an error condition that would absolutely have been detected prior to
product delivery, so I can understand the argument against in that case. But
who knows what other undetected/untested problems may be lurking out there?

I've come across the explanation that catching too big of a superclass can
hide or mask serious errors that you weren't expecting.

However, I've also seen a couple places that say it is appropriate in certain
instances, such as on a server application, or when you absolutely don't want
to crash.

If it's only to catch NoClassDefFoundError, then not only it won't
work all the time and moreover there's a better alternative, clearly
explained in Joshua Bloch and Neal Gafter's
"Java Puzzlers" book. Puzzle 44: "Cutting Class".

A small excerpt:

"In summary, *do not depend on catching NoClassDefFoundError.
"The language specification carefully describes when class
"initialization occurs [JLS 12.4.1], but class loading is far less
"predictable. More generally, *it is rarely appropriate to catch
"Error or its subclasses*. These exceptions are reserved for
"failures from which recovery is not feasible.

A NoClassDefFoundError can be worked around by using
reflection and catching a ClassNotFoundException (which, as
it names implies, is not an Error).

So remember that catching Throwable will not even catch
all NoClassDefFoundError.

I was already catching Exception, but the ClassNotFoundException wasn't being
thrown... I'm not too familiar with reflection, guess I'll have to come up to
speed on it.


scott

 

[James McGill]

However, I've also seen a couple places that say it is appropriate in
certain
instances, such as on a server application, or when you absolutely
don't want
to crash.

Another way of looking at this, is if you've caught an undeclared
throwable (e.g., runtime exception) you've *already* crashed.

 

[Chris Uppal]

I've come across the explanation that catching too big of a superclass can
hide or mask serious errors that you weren't expecting.

This is true, but like all rules you shouldn't apply it blindly.

However, I've also seen a couple places that say it is appropriate in
certain
instances, such as on a server application, or when you absolutely don't
want
to crash.

I'd say that there are circumstances where it is appropriate to catch
Throwable, but that they are not the same as "you absolutely don't want to
crash". There is no guarantee that a Throwable exception is recoverable, and
it may be that the best you can hope for is to provide better diagnostics than
a stack trace written to the console (if the application is even connected to
one). The other reason why it might be "correct" to catch throwable is if the
application is stuctured in separate "sessions" (in some general sense) where
problems in one session should not (if at all possible) disrupt other sessions.
So, for instance, a server might catch and log Throwable exceptions in each
session, and attempt to close the problematic session without affecting any
others. It might be that there was no way to recover, but if so then catching
Throwable wouldn't make the inevitable crash any worse, and it might allow it
to continue after unanticipated, but not /globally/ fatal errors.

-- chris

 

[Sebastian Millies]

Am Tue, 9 May 2006 10:57:36 +0100 schrieb Chris Uppal:

others. It might be that there was no way to recover, but if so then catching
Throwable wouldn't make the inevitable crash any worse, and it might allow it
to continue after unanticipated, but not /globally/ fatal errors.

-- chris

Isn't that what happens by default when one starts a new thread in a
multithreaded application? I believe the default behavior of the jvm
is to print a stack trace of any uncaught exception when it exits the
run-Method, and not affect any other running threads. Is that correct?
-- Sebastian

 

[Chris Uppal]

Sebastian Millies wrote:

[me:]

others. It might be that there was no way to recover, but if so then
catching Throwable wouldn't make the inevitable crash any worse, and it
might allow it to continue after unanticipated, but not /globally/
fatal errors.

[,,,]
Isn't that what happens by default when one starts a new thread in a
multithreaded application? I believe the default behavior of the jvm
is to print a stack trace of any uncaught exception when it exits the
run-Method, and not affect any other running threads. Is that correct?

Now you mention it, I believe the JVM does behave that way. I had forgotten.

Not quite the same thing as I was describing, though, although the ideas are
clearly similar.

-- chris

 

[Don Young11]

Avoid catching throwable unless you have to

Java Errors subclasses are by design assosiated with unrecoverable situations in which it's better to quit the app, which will force the user to understand that something wrong had happen, than to continue limping on one foot, I found a good example for this in this article: javatuning.com/why-catch-throwable-is-evil-real-life-story/