aspose file tools*
The moose likes Features new in Java 7 and the fly likes Handling More Than One Type of Exception - What is the value add? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Features new in Java 7
Bookmark "Handling More Than One Type of Exception - What is the value add?" Watch "Handling More Than One Type of Exception - What is the value add?" New topic
Author

Handling More Than One Type of Exception - What is the value add?

Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

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
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
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:
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

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.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
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
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

Thank you Mike. That explains well.
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

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 :-)


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40038
    
  28
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.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

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).
Stuart A. Burkett
Ranch Hand

Joined: May 30, 2012
Posts: 679
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
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40038
    
  28
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.
 
jQuery in Action, 2nd edition
 
subject: Handling More Than One Type of Exception - What is the value add?