Need authoritative source for why you shouldn't throw or catch java.lang.Exception

Question

I\'ve got a coding standards meeting in just over an hour and I need a quick answer to this one.

Common wisdom among experienced Java programmers is that you don\'t

Answer 1

where they catch a subclass of java.lang.Exception, log an error, and rethrow the subclass as java.lang.Exception. I need to convince them that they need to stop writing code like this.

I agree they should use another tactic, but for different reasons. There's not much sense in catching an exception just to log it and rethrow it.

An alternative is: don't catch the exception and let some higher up code (like a Java EE Filter, or try/catch in your main() method) catch and log all uncaught exceptions. Then you ensure each exception is only logged once, and you know all uncaught exceptions will be logged.

If you need to add extra information to the exception, catch it, change the message and rethrow it. I usually use a RuntimeException for this:

} catch (Exception originalException) {
    throw new RuntimeException("user name was " + userName, originalException);
}

Answer 2

Here is Bruce Eckel's viewpoint on checked exceptions in general, which is that in most cases they are a bad idea. Maybe that will have something that you can use.

Answer 3

See this article from Brian Goetz (the concurrency wizard) who has his own insight as well as quoting Josh Bloch in Effective Java

Answer 4

I guess the point is that if you don't know how to handle a specific exception then you shouldn't catch it. It should propagate to a higher level in the hopes that it might know what to do with it. Catching exceptions too early leads to exceptions being swallowed silently and makes it impossible to do anything useful with them beyond logging.

Imagine what would happen if FileInputStream's constructor were to log an exception internally if you tried opening a file that did not exist, but didn't indicate this failure to your code. It's fine that the error gets logged but your code would like to catch this exception and do something useful with it (such as prompting the user for a new filename). If they were to catch (Exception) you wouldn't be able to do this.

Answer 5

There is no common ground here. You will find two groups:

1. Those who hate checked exceptions will catch and wrap them in a RuntimeException of some kind.

2. Those who hate RuntimeException

The first group hates to riddle their code with try...catch, especially since in most cases, you can't handle the exception when you first see it. Think IOException: It could be thrown for every byte that your read. What's the low level code to do about it? It has to rethrow it so someone higher up can add some useful context to the error (like which file you were reading).

The other group wants to see what could go wrong. RuntimeException effectively hides this.

There is a simple fix, BTW: Make Exception extend RuntimException. Insane? Not really. If you do that with JDK 7, you get two compile errors.

The next step would be to have all Java compilers enumerate all runtime exceptions and list them in the throws entry in the class file. You still don't have to catch them but now, you'll know which ones could happen.

Lastly, extend the IDEs to display this. And presto, both groups could be happy. Unfortunately, this won't happen.

Answer 6

Here's something: Java Tip 134: When catching exceptions, don't cast your net too wide (JavaWorld)

Effective Java (Second Edition) by Joshua Bloch might have something on this in Chapter 9 (Exceptions), although I couldn't quickly find anything about not catching Exception.

Here is a Q&A from JavaWorld about the question (also points to Java Tip 134) - it also explains why you sometimes have to break the rule of not catching Exception or even Throwable.