Java: Meaning of catch (final SomeException e)?

Question

What does final do in the following Java expression?

catch (final SomeExceptionType e)

Answer 1

Currently it means final much the same as any local variable, other than it is always "definitely assigned".

In recent JDK7 builds, a Project Coin language change allows it to indicate a degree of implicit static typing is going on. A single catch can catch a number of different checked exceptions by a common base type, and rethrow with the enclosing context only having catch or declare those exceptions that could (statically speaking) be thrown within the try. (See the link for a better explanation.)

Answer 2

The question, "What does finally do?" is addressed in other answers to this question, and here, here, and here. But in the context of a try-catch block, the Java Language Specification (JLS) §4.12.4 states (emphasis my own):

• A resource of a try-with-resources statement (§14.20.3) and an exception parameter of a multi-catch clause (§14.20) are implicitly declared final.
• An exception parameter of a uni-catch clause (§14.20) may be effectively final instead of being explicitly declared final. Such a parameter is never implicitly declared final.

In a multi-catch clause:

Adding the final keyword to a multi-catch clause simply makes explicit the fact that the variable is implicitly final. In general, whenever the final keyword conveys additional information that helps make your code more readable/maintainable, use it.

In a uni-catch clause

On the other hand, the exception parameter in a uni-catch clause is never implicitly final. So, using the final keyword to a uni-catch clause prevents something like the following from happening:

try {
     throw new Exception();
catch (Exception e){
    e = null;
    e.printStackTrace(); //throws a NullPointerException
}

The issue is obvious in this simple example. But two cases may be less obvious and warrant the use of finally:

1. If the catch block is more complicated, accidental reassignment is possible. (Although, if the catch block is complicated, you're probably doing it wrong.)
2. To prevent issues caused during code maintenance. Adding final to the exception variable will ensure reassignment is caught at compilation, rather than Runtime

As a general rule of thumb, use the final keyword in a uni-catch clause in the same way you would use the final keyword for a method parameter:

JLS§4.12.4 : Declaring a variable final can serve as useful documentation that its value will not change and can help avoid programming errors.

Answer 3

The final keyword on variables means that the variable can only be assigned once, and as the assignment here is being done by the compiler it means that the variable cannot be changed later in the code.

This is an important property as it means to the maintainer that this particular variable will have this particular value everywhere it is used and it is not necessary to keep track of where it changes. This is recognized to be so useful that the "Clean up" action in Eclipse allows for adding "final" whereever it possibly can, and I believe that what you see is the result of such an automatic clean up, because most human programmers would keep the catch-block short so such an indication is not needed.

Answer 4

It basically means:

Catch "SomeExceptionType" into the variable "e" with the promise that we won't assign a different exception to "e" during the processing of the exception.

Mostly this is overkill, as if I'm catching an exception into a temporary variable name (e only is valid for the exception handling block), I don't have to police myself so strictly as to not trust myself to assign a different (possibly created) exception to the same variable name.

That said, perhaps this block is heavily maintained by a team of different-minded individuals, and one just wanted to be VERY sure that e was the original captured exception.

---- Edited in response to commentary ----

I can't think of a really excellent reason to do this. Since "e" is not a member (static or otherwise) the name "e" won't be used by the class file post-compilation. Another way of stating this is that when you enter the exception handling block of JVM bytecode, the object won't be assigned to any of the member names accessible by the JVM processing frame, it will be pushed to the internal processing stack of the Thread's current frame.

Even if two threads had access to the same Object, each thread would have it's own frame, so the compiler removed "e" name from one frame's internal stack couldn't be altered by the other thread.

With that in mind, the only benefit of declaring "e" final is to make sure that future coders don't accidentally set "e" after entering the block. Perhaps they meant to make the code more robust in a multi-threaded environment, but temporary variables (those with names that only are valid in the block) don't have names post-compilation, they are pushed onto the frame's stack.

That's why

public int safe() {
  int x = 5;
  x = x + 5;
  return x;
}

is generally regarded as thread safe, because it does this (in pseudo bytecode)

(In the thread's current frame)
push 5
push 5
add integers
return

While this isn't thread safe

int x = 5;

public void unsafe() {
  x = 5;
  x = x + 5;
  return x;
}

because it does this

(in the thread's current frame)
push "this"
push 5
set member x
push "this"
get member x
push 5
add integer
set member x
get member x
return

The latter bytecode makes it apparent that interleaving two threads creates thread-to-thread communications using member x an an intermediary, while the first block of code cannot have any inter-thread communication because there's no intermediary.