• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Shiv Swaminathan
Ranch Hand
Posts: 48
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 48
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 48
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Mike. That explains well.
 
Martijn Verburg
author
Bartender
Posts: 3275
5
Eclipse IDE Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 :-)
 
Campbell Ritchie
Sheriff
Pie
Posts: 50277
80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 679
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 50277
80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic