aspose file tools*
The moose likes Features new in Java 7 and the fly likes Handling more than one Exception in a Catch Block Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Features new in Java 7
Bookmark "Handling more than one Exception in a Catch Block" Watch "Handling more than one Exception in a Catch Block" New topic
Author

Handling more than one Exception in a Catch Block

Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

One more cool feature of Java 7 is handling multiple exceptions in the same catch block.
When we use this feature we must note that

" 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."

Will this limit my freedom in custom handling the exception?
Why should the Exception parameter be made final by Java?


SCEA EE5, CSM, PMP, IBM OOAD with UML, SCDJWS, SCWCD, SCJP 1.5
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19543
    
  16

Ask yourself this: inside this catch block, what value could you give e, other than null? To prevent having to check if an assignment would be possible, Oracle decided to disallow assignment completely. Makes sense to me.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 973
    
    5

Will this limit my freedom in custom handling the exception?

I don't see how. What custom handling were you thinking of?
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

@James, By additional custom handling I meant things like I want to add some more details to the stack trace...
Say we were catching a custom application created exception class and on the caught exception we are trying to add more to the stack trace during handling...

@Rob, probably I misunderstood, so you are saying the reference variable is final but not the exception object itself?
Which means we must be able to modify the exception object caught like quoted to @James above. (An arbitrary example)
I agree that we don't have a need to reassign a value to the exception variable or nullify it within the catch block.
But what is the difference between the normal single exception catch and multiple exception catch of Java 7. Why is the exception variable not final for single exception catch and why final only during multiple exception catch?

Any ideas why this snippet of code is showing a compilation error with Java 7:



The error shown: The exception FileNotFoundException is already caught by the alternative IOException

Did your code snippet compile with Java 7, its almost similar to the above exception handling I tried:


Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3056
    
  33

Shiv Swaminathan wrote:


The error shown: The exception FileNotFoundException is already caught by the alternative IOException


FileNotFoundException extends IOException hence not allowed in the multicatch block.


Mohamed Sanaulla | My Blog
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

My Bad! I thought SQLException was also extending IOException...

Thank you @Mohamed.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19543
    
  16

Shiv Swaminathan wrote:@Rob, probably I misunderstood, so you are saying the reference variable is final but not the exception object itself?
Which means we must be able to modify the exception object caught like quoted to @James above. (An arbitrary example)

Correct; objects are never final, that's a property reserved for classes, methods and variables. A final reference can still refer to a mutable object. Although it's very unusual to have mutable exceptions (apart from the cause that is, but that only be set once).
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
Rob Spoor wrote:. . . Although it's very unusual to have mutable exceptions (apart from the cause that is, but that only be set once).
This method of SQLException makes it mutable, and I thought that was the only well‑known example.
But every Exception has this method, which means they are all mutable and we never noticed.
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

Yes that's exactly what I meant could be a possible action during a custom exception handling... meaning trying to add some more stack trace elements...

But what still puzzles me is:

(Though I understand that there might not be a need to do reassignments to the exception parameter inside the catch block)

why is the exception parameter not final for a single exception catch block and why is it final for multiple catch exception block.
From a parameter sense I don't sense/context, there is no difference between these two scenarios.

Or am I still missing some connecting piece here.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

I actually know the answer to this

The "final" makes it possible for the compiler to know very specifically what exceptions can be rethrown from a multicatch.

Imagine you have the following Java 6 code, where you need to do some kind of error processing before rethrowing an exception:



That is the kind of repetitive code we all hate. Sometimes you rewrite it like this, but it makes you feel dirty to do so:



The part that makes you feel bad is that "throws Exception" declaration. You've had to throw type information away to gain compactness. Meh.

Along comes multicatch, and you can write this (hurray!):



This is the best part of multicatch, in my opinion. You can handle multiple types in one block without losing the exception type information. The compiler understands that the type of a rethrow is the list of types in the multicatch.

Now, how does this work? It turns out that the compiler generates the same executable code for the previous two cases: one single catch block that processes the exception argument. The exception table contains two entries, one for each of the two exception types. But what is the static type of "ex"? It's the nearest common relative of all the exception types: let's say it's just "Exception". The precise "throws" list of "doSomethingElse()" is an illusion, because the compile-time type of the thrown object is much, much broader. But the compiler thinks it knows what the runtime types are based on the list of types in the multicatch.

But what if I wanted to be a troublemaker, and I did this:



Oh oh! The method signature promises that the method will only throw XException or YException, but it's throwing ZException! And the compiler can't stop you, because the compile time type of "ex" is "Exception", and the assignment is perfectly legal.

Unless...

Unless we make "ex" final, plugging the hole. And that, my friends, is the answer you're looking for. The exception reference is final to enable precise rethrow semantics.


[Jess in Action][AskingGoodQuestions]
Ivan Jozsef Balazs
Rancher

Joined: May 22, 2012
Posts: 865
    
    5
> And the compiler can't stop you, because the compile time type of "ex" is "Exception"

Well, in theory you could support an implicit multitype feature in the compiler for this case, and then it could know that ex can be assigned an X or a Y but not a Z Exception, but the way you described is a better fit to the existing type handling.
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

@Ernest - Good Explanation and I did experiment a little more based on your explanation. Thanks a ton, I read your response the first thing my morning and it was more refreshing than my morning coffee
Did not get a chance to reply early...

For the current complication technique as @Ivan says, this is perfect analysis - Current Java Compiler does not know which type of exception we are creating within the multiple catch block, if we want to make a reassignment to the exception argument.

Following code for single catch block compiled..



I was not able to assign any other type of Exception object to 'ex' other than its declared type IOException or a subclass of IOException like FileNotFoundException...
This explains your case on how the compiler could do type referencing at compile time for single catch and a reason for the argument not kept as final here.

May be Java should in the future enhance its compiler to identify the exception types in multiple catch block and not make the exception argument final.
Compiler should check against all exception types instead of making this workaround. When it knows to do for single exception hierarchy why not for one more in the expression...

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Shiv Swaminathan wrote:May be Java should in the future enhance its compiler to identify the exception types in multiple catch block and not make the exception argument final.
Compiler should check against all exception types instead of making this workaround. When it knows to do for single exception hierarchy why not for one more in the expression...

Or maybe in the future, people who want to do this sort of thing can just declare a new local variable, rather than re-using the catch block parameter?

Of course, if you're just going to throw the new exception, there's no need to assign it to a variable at all. Just throw it!
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48



I agree @Mike!

But it will be good to have both single catch and multiple catch exception argument to be treated in a consistent way...
Manuel Petermann
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

Shiv Swaminathan wrote:
But it will be good to have both single catch and multiple catch exception argument to be treated in a consistent way...


Problem being if you would allow that, you would make assignment of objects inconsistent, which I think is far more important.


Please correct my English.
Shiv Swaminathan
Ranch Hand

Joined: Jul 21, 2010
Posts: 48

Manuel Petermann wrote:
Shiv Swaminathan wrote:
But it will be good to have both single catch and multiple catch exception argument to be treated in a consistent way...


Problem being if you would allow that, you would make assignment of objects inconsistent, which I think is far more important.


Can you please elaborate on this point...I feel a little lost...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Handling more than one Exception in a Catch Block
 
Similar Threads
unreachable statement again
performance degradation in using try/catch
Handling More Than One Type of Exception - What is the value add?
try catch block
Exception