Handling more than one Exception in a Catch Block

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?

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

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

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.

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.

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

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

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!