views:

1546

answers:

4

Sometimes, you just have to catch Throwable, e.g. when writing a dispatcher queue that dispatches generic items and needs to recover from any errors (said dispatcher logs all caught exceptions, but silently, and then execution is continued on other items).

One best practice I can think of is to always rethrow the exception if it's InterruptedException, because this means someone interrupted my thread and wants to kill it.

Another suggestion (that came from a comment, not an answer) is to always rethrow ThreadDeath

Any other best practices?

+6  A: 

Probably the most important one is, never swallow a checked exception. By this I mean don't do this:

try {
  ...
} catch (IOException e) {
}

unless that's what you intend. Sometimes people swallow checked exceptions because they don't know what to do with them or don't want to (or can't) pollute their interface with "throws Exception" clauses.

If you don't know what to do with it, do this:

try {
  ...
} catch (IOException e) {
  throw new RuntimeException(e);
}

The other one that springs to mind is to make sure you deal with exceptions. Reading a file should look something like this:

FileInputStream in = null;
try {
  in = new FileInputStream(new File("..."));;
  // do stuff
} catch (IOException e) {
  // deal with it appropriately
} finally {
  if (in != null) try { in.close(); } catch (IOException e) { /* swallow this one */ }
}
cletus
+1 on the never swallow a checked exception - even in your 'first pass.' too often these things get overlooked and ultimately submitted to source control. if in doubt, at least print the stack trace.
akf
If you can't handle it and can't rethrow it, at least print that stack trace! A stack trace in the log is a great help in diagnosing the problem.
starblue
The horror of checked Exceptions... catch IOException only to wrap it in a non-checked exception and NOT do anything with it at all? Of course, that's what you have to do in Java, unless you actually know why you're getting the Exception.
Yar
-1 The question is about catching throwables and best techniques, it is NOT about swallowing checked exceptions.
Kalecser
When did Java add catch(Throwable) ? Or has it always been there and I didn't know about it?
Chris S
+1  A: 

Depends on what you are working on.

if you are developing an API to be used by some one else, its better to re-throw the Exception or wrap it into a custom exception of yours and throw.

Whereas if you are developing an enduser application you need to handle this exception and do the needful.

Ratnesh Maurya
A: 

I would not catch Throwable directly.

The question is why do you have to catch throwables. Can you give an example of a usecase where you realy have to catch a throwable.

Most of the time the input contains any errorswhen a throwables are thrown. When the input is correct, the progress should never thrown any type of throwables, without checked exceptions.

If you expect throwables like InterruptedException you have to catch these exception directly.

Markus Lausberg
I have given the example in the body of the question.
ripper234
if you're writing a framework that runs other people's code, you must catch anything they throw.
Scott Stanchfield
+1  A: 

If you're writing a dispatcher queue, then by the time the exception comes back to you there's no point in doing anything with it other than logging it. The Swing event queue has basically that type of behavior.

Alternatively, you could provide a hook for an "uncaught exception handler," similar to ThreadGroup. Be aware that the handler could take a long time, and end up delaying your dispatcher.

As far as InterruptedException goes: the only thing that cares about that is your dispatch loop, which should be checking some external state to see if it should stop processing.

kdgregory
Why is checking an external state better than using InterruptedException as a signaling mechanism?
ripper234
Because InterruptedException simply indicates that someone called interrupt() on the thread. There could be multiple reasons for doing this, not just terminating the current action. And if you do want to use interrupt() to terminate the dispatcher, you certainly don't want to throw it; simply return from run() -- unless, of course, your dispatcher isn't the only thing that thread is doing, but even there, you almost certainly don't want to blindly throw.
kdgregory