Is there any sense in using final keyword in catch block?

[Royan]

The question is simple, does it make sense to add final keyword like
in the example below?

try {
// code
} catch (final XxxxException e) {
// do exception handling
}

Whether it makes sense or not, please justify your answer.

 

[RedGrittyBrick]

The question is simple, does it make sense to add final keyword like
in the example below?

try {
// code
} catch (final XxxxException e) {
// do exception handling
}

Whether it makes sense or not, please justify your answer.

Homework?

 

[Joshua Cranmer]

The question is simple, does it make sense to add final keyword like
in the example below?

try {
// code
} catch (final XxxxException e) {
// do exception handling
}

Whether it makes sense or not, please justify your answer.

Does it make sense to add the final keyword to a local variable?

Do you know what the ramifications of doing so are?

If you can answer those two questions, you should be able to translate
the semantics of the final keyword to the example and explain why it
would or would not make sense.

 

[Royan]

Does it make sense to add the final keyword to a local variable?

Do you know what the ramifications of doing so are?

If you can answer those two questions, you should be able to translate
the semantics of the final keyword to the example and explain why it
would or would not make sense.

Guys this is a serious question and is actually aimed to reveal any
JIT optimizations (if any), best practices or whatever.

I've read a couple of articles regarding the usage of final keyword,
and to the moment the most interesting point I've read regarding its
usage in the catch block was about upcoming changes in java. Check out
this article: http://weblogs.java.net/blog/emcmanus/archive/2008/05/javaone_report.html

 

[Daniel Pitts]

The question is simple, does it make sense to add final keyword like
in the example below?

try {
// code
} catch (final XxxxException e) {
// do exception handling
}

Whether it makes sense or not, please justify your answer.

It is often a stylistic thing. My personal style is to make fields and
local variables final, but leave parameters/catch as not final.

This is completely arbitrary. My ideal would have been if Java had made
every field/parameter/local final by default, and the programmer could
specific nonfinal for things they really wanted to change.

 

[Joshua Cranmer]

Guys this is a serious question and is actually aimed to reveal any
JIT optimizations (if any), best practices or whatever.

Your original question sounds copied verbatim from some homework
assignment. As I said earlier, a final in a catch statement means the
same as any other final local variable.

I've read a couple of articles regarding the usage of final keyword,
and to the moment the most interesting point I've read regarding its
usage in the catch block was about upcoming changes in java. Check out
this article: http://weblogs.java.net/blog/emcmanus/archive/2008/05/javaone_report.html

That's not upcoming changes:
"They followed with two proposals for exception handling..."

I doubt that the second proposal (the one that changes the implication
of final) would be accepted over the first one.

 

[Mike Schilling]

It is often a stylistic thing. My personal style is to make fields
and local variables final, but leave parameters/catch as not final.

This is completely arbitrary. My ideal would have been if Java had
made every field/parameter/local final by default, and the
programmer
could specific nonfinal for things they really wanted to change.

for (nonfinal int i = 0; i < 10; i++)

Yup, a *big* improvement.

 

[Tom Anderson]

My style is to not use final for local variables (including parameters and
catch variables) at all. Unless they're being closed over by an anonymous
class, where it's required. I think the point of a final qualifier is to
reassure the programmer (reading or writing the code) that it won't change
unexpectedly - it's an aid to reasoning about the code. Instance variables
can be read and written from anywhere in the class (or even outside, if
they're not private), and thus in a class of more than trivial size, it
can be hard to keep track of whether that's happening, and where.
Declaring a field final eliminates this difficulty at a stroke. However,
local variables can only be accessed from inside the method they're local
to; that's a much smaller body of code that the programmer has to keep in
mind to know everything about the variable's use. There, i don't think
there's much uncertainty to be reduced, and the additional keywords just
clutter up the screen and mean more letters to type.

Note that for this analysis to hold, your methods have to be short: small
enough that you can hold the whole thing in your mind at once. However, i
would say that this is exactly how methods should be. If your method is
big enough that making its locals final is helping you, then you need to
split it up into multiple smaller methods. Essentially, final locals are a
code smell.

I quite like this idea too. I'd want to see how it felt in practice before
i fully supported it, though.

for (nonfinal int i = 0; i < 10; i++)

Yup, a *big* improvement.

Even better, IMHO:

for (variable int i = 0; i < 10; i++)

!

tom

 

[Lew]

My style is to not use final for local variables (including parameters and
catch variables) at all. Unless they're being closed over by an anonymous
class, where it's required. I think the point of a final qualifier is to
reassure the programmer (reading or writing the code) that it won't change
unexpectedly - it's an aid to reasoning about the code. Instance variables
can be read and written from anywhere in the class (or even outside, if
they're not private), and thus in a class of more than trivial size, it
can be hard to keep track of whether that's happening, and where.
Declaring a field final eliminates this difficulty at a stroke. However,
local variables can only be accessed from inside the method they're local
to; that's a much smaller body of code that the programmer has to keep in
mind to know everything about the variable's use. There, i don't think
there's much uncertainty to be reduced, and the additional keywords just
clutter up the screen and mean more letters to type.

There are also implications of 'final' for thread safety.

 

[Daniel Pitts]

There are also implications of 'final' for thread safety.

It is truly unfortunate that Java hasn't the same concept of "const
reference" that C++ does. It would make Java code so much easier to
verify as thread-safe and otherwise bug-free.

 

[Arne Vajhøj]

The question is simple, does it make sense to add final keyword like
in the example below?

try {
// code
} catch (final XxxxException e) {
// do exception handling
}

Whether it makes sense or not, please justify your answer.

I consider it unnecessary cluttering of the code.

Arne

 

[Arne Vajhøj]

It is truly unfortunate that Java hasn't the same concept of "const
reference" that C++ does. It would make Java code so much easier to
verify as thread-safe and otherwise bug-free.

I also miss that a lot.

But I am not sure how easy it would be to implement with all
those libraries that use reflection.

Arne