An authoritative source is needed, why you shouldn't throw or catch java.lang.Exception

Question

I have coding standards standards in just an hour, and I need a quick answer to this question.

The common wisdom among experienced Java programmers is that you don’t throw or catch java.lang.Exception (with rare exceptions, the pun is not intended). The reason you do not do this is because the statement

catch (java.lang.Exception ex) {...} 

also catches unverified exceptions, and in most cases this is not what is supposed to be.

We already have a lot of legacy code written by existing team members where they catch a subclass of java.lang.Exception, register an error, and restructure the subclass as java.lang.Exception.

I need to convince them that

• They need to stop writing such code.
• Existing code that uses this anti-pattern must be fixed.

Number 2 means a fair amount of refactoring.

He will reduce the argument in the meeting if I can show the article or blog entry to one of the heavyweights of the Java community that does this (e.g. Joshua Bloch, James Gosling). My google-fu hasn't added anything yet.

Does anyone know an article or blog from a reputable Java guru that says you shouldn't throw or catch java.lang.Exception?

Quick replies are much appreciated.

Dean

Answer 1

Here's something: Java Tip 134: When catching exceptions, don't use your network too widely (JavaWorld)

Effective Java (Second Edition) Joshua Bloch may have something in this in Chapter 9 (Exceptions), although I could not quickly find anything about not catching the Exception .

Here's the Q&A from JavaWorld about the question (also pointing to Java Tip 134) - this also explains why you sometimes have rules for not breaking Exception or even Throwable for breaking the rule.

Answer 2

See this article by Brian Goetz (concurrency master), who has his own understanding and also quoting Josh Bloch in "Effective Java"

Answer 3

Here's Bruce Eckel 's point of view on checked exceptions in general , that is, in most cases this is a bad idea. Maybe this will have something you can use.

Answer 4

There is no common point. You will find two groups:

• Those who hate checked exceptions will catch and wrap them in a RuntimeException .

• Those who hate RuntimeException

The first group hates guessing their code with try...catch , especially since in most cases you cannot handle the exception when you first see it. Think of an IOException : it can be thrown for every byte that you read. What low level code do I need to do? He needs to rebuild it so that someone above can add useful context to the error (for example, which file you read).

Another 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 this using JDK 7, you will get two compilation errors.

The next step should be to have all Java compilers list all exceptions at runtime and list them in the throws entry in the class file. You still do not need to catch them, but now you will know which ones can happen.

Finally, extend the IDE to display this. And presto, both groups could be happy. Unfortunately, this will not happen.

Answer 5

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

I agree that they should use a different tactic, but for different reasons. There is not much point in catching an exception, just registering it and repairing it.

An alternative is: do not catch the exception and do not let the higher code (for example, Java EE Filter, or try / catch in your main () method) catch and catch all uncaught exceptions. Then you guarantee that each exception is logged only once, and you know that all uncaught exceptions will be logged.

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

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

Answer 6

this is a long article, but this offers you:

• use checked exceptions when the client expects this error to occur regularly and should process it (for example: the data entered by the user did not pass verification)
• use unchecked exceptions for unforeseen conditions (for example: the database server is down)

In theory, # 1 (expected errors) should have its own type of exception, and the only place that # 2 (RuntimeException) should catch is some type of top-level handler that catches the exception, logs it and shows the user an error message, and even here you should probably catch a Throwable to make sure that any uncaught exceptions are handled.

Following these recommendations, you should not catch the exception, since it does not meet any of the above criteria (which means that it is not a RuntimeException, and it is not a specialized substructure of the Exception to indicate the expected error).

Answer 7

Here is a very insightful article

Summary:

• Use verified exceptions for rare but valid contingencies that are relevant to the purpose of your code. Client code must know how to handle them.

• Use excluded exceptions for errors that should not occur but do. (Server crash, misconfiguration, SQL syntax error, etc.) The IT guy who runs the server, or the developer who just passed bad SQL to prepare State (), needs to know how to fix these problems. Errors must be propagated to the registration level so that information is not lost.

Answer 8

I assume that the fact is that if you do not know how to handle a particular exception, you should not catch it. It should spread to a higher level in the hope that it can know what to do with it. Capturing exceptions too early causes the exceptions to be swallowed silently and makes it impossible to do anything useful with them outside the protocols.

Imagine what would happen if the FileInputStream constructor FileInputStream supposed to register an internal exception if you tried to open a file that did not exist, but did not indicate this error in your code. It’s good that the error is logged, but your code would like to catch this exception and do something useful with it (for example, invite the user for a new file name). If they were catch (Exception) , you would not be able to do this.

Answer 9

If you have a copy of Josh Bloch Effective Java, I know that it handles exceptions very well. I don’t have access to it at present, so I can’t generalize it or give you links to pages, but I am sure that it has good arguments that it did not catch java.lang.Exception.