Handling more than one Exception in a Catch Block

[Shiv Swaminathan]

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?

[Rob Spoor]

catch (SQLException | IOException e)

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.

[James Boswell]

Will this limit my freedom in custom handling the exception?

I don't see how. What custom handling were you thinking of?

[Shiv Swaminathan]

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

} catch (FileNotFoundException | IOException ex) {

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:

catch (SQLException | IOException e) 

[Mohamed Sanaulla]

Shiv Swaminathan wrote:

} catch (FileNotFoundException | IOException ex) {

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

FileNotFoundException extends IOException hence not allowed in the multicatch block.

[Shiv Swaminathan]

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

Thank you @Mohamed.

[Rob Spoor]

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]

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]

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]

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:

void doSomething() throws XException, YException {}

void doSomethingElse() throws XException, YException {
    try {
    } catch (XException x) {
        x.printStackTrace(); throw x;
    } catch (YException y) {
        y.printStackTrace(); throw y;
    }
}

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:

void doSomething() throws XException, YException {}

void doSomethingElse() throws Exception {
    try {
    } catch (Exception ex) {
        ex.printStackTrace(); throw ex;
    } 
}

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

void doSomething() throws XException, YException {}

void doSomethingElse() throws XException, YException  {
    try {
    } catch (XException | YException ex) {
        ex.printStackTrace(); throw ex;
    } 
}

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:

void doSomething() throws XException, YException {}

void doSomethingElse() throws XException, YException  {
    try {
    } catch (XException | YException ex) {
        ex.printStackTrace(); ex = new ZException(); throw ex;
    } 
}

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.

[Ivan Jozsef Balazs]

> 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]

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

void doSomethingElse() throws IOException  {
		FileReader reader = null;
		try {
	    	reader = new FileReader("C:/Users/Sivasankari/Documents/Lookup.txt");
	        int i=0;
	        while(i != -1){
	            i = reader.read();
	            System.out.print((char) i );
	        }
	        System.out.println("--- File End ---");
	    } catch (IOException  ex) {
	        ex.printStackTrace(); 
	        ex = new FileNotFoundException(); 
	        throw ex;
	    } 

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]

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?

    } catch (IOException  ex) {  
        ex.printStackTrace();   
        FileNotFoundException ex2 = new FileNotFoundException();   
        throw ex2;
    }

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!

    } catch (IOException  ex) {  
        ex.printStackTrace();   
        throw new FileNotFoundException();   
    }

[Shiv Swaminathan]

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]

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.

[Shiv Swaminathan]

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