Handling More Than One Type of Exception feature of Java 7 helps to capture multiple exceptions at one shot in a single catch block. So less code. Nice!
But the exception parameter is catch is final. So we cannot add to the stack trace or append to the exception message. Does this really add value? or did I overlook the value add?
SCEA EE5, CSM, PMP, IBM OOAD with UML, SCDJWS, SCWCD, SCJP 1.5
I'd say the value add is what you said in the first place - you can eliminate redundant code. If you want to add additional stack trace or message info, the usual approach is to throw a new exception that wraps the original one:
So what does this note exactly mean and how does it narrow down my options from the normal way of catch single exception and catch multiple exception.
Consider the following example, which contains duplicate code in each of the catch blocks:
In releases prior to Java SE 7, it is difficult to create a common method to eliminate the duplicated code because the variable ex has different types.
The following example, which is valid in Java SE 7 and later, eliminates the duplicated code:
If a catch block handles more than one exception type, then the catch parameter is implicitly final. In this example, the catch parameter ex is final and therefore you cannot assign any values to it within the catch block.
Joined: Mar 05, 2008
It means you can't do something like this:
because the reference variable "ex" is implicitly final. The compiler has determined that ex is either an IOException or a SQLException, and they want to make sure you don't change it to something completely different. But so what? You don't need to reassign ex to anything else, and you can still handle the exception however you want - such as
Interestingly when Joe Darcy (Oracle lead on Project Coin) did the empirical analysis on this they found that 99.8% of catch block Exceptions were effectively final, hence they omitted the need to put final in there and made the final characteristic implicit. Sometimes I wish that Java was final by default and that you'd have a keyword to denote not final :-)
If SomeException and OtherException don’t inherit from each other, then how can you re‑assign the ex reference? It does not have a type you can assign anything to.
If SomeException and OtherException do inherit from each other, then why are you trying to put them into the same catch? You only need to catch an instance of the superclass.
Campbell Ritchie wrote:If SomeException and OtherException don’t inherit from each other, then how can you re‑assign the ex reference? It does not have a type you can assign anything to.
The type of an exception parameter with a union is the most specific common supertype of the two. Which is often likely to be Exception, and will always be Throwable or something more specific. So it could have been allowed to assign anything compatible with that (though I think it makes sense that it's not allowed).
Campbell Ritchie wrote:If SomeException and OtherException do inherit from each other, then why are you trying to put them into the same catch? You only need to catch an instance of the superclass.
There might be other exceptions that inherit from the superclass that you want to handle differently. For example if SomeException, OtherException and SomeOtherException are related by inheritance
Joined: Oct 13, 2005
But if that example is to mean anything, SomeException and OtherException are not superclass and subclass to each other. When I said related, I wasn’t clear. I meant they were superclass and subclass to each other, or vice versa.