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

On Thu, 23 Oct 2008, Mike Schilling wrote:

Daniel Pitts wrote:
Royan wrote:

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.

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.

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.

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

--
Virtually everything you touch has been mined. -- Prof Keith Atkinson
.

Relevant Pages

  • Re: Long.valueOf(long) CodeAttribute max_locals wrong?
    ... final int offset = 128; ... view" of local variables, or with the JVM view of local variables? ... Compiling code with debug information should provide proper initialization code for the final int offset, because debuggers may access the names and/or values of the local variables. ... public class Locals { ...
    (comp.lang.java.machine)
  • Re: proc A def/calls proc B: variable scoping rules.
    ... no. Scoping and duck typing are completely different concepts. ... # define both a and b as locals ... first it searches for it in the function's local variables, ...
    (comp.lang.python)
  • Re: Local variables controversial?
    ... >>> if you keep them on the stack the stack is minimally 4 deep, ... >> Graphics always comes up when locals are discussed. ... >> that don't ever require substandial stack thrashing OR local variables. ...
    (comp.lang.forth)
  • RfD: Enhanced local variable syntax
    ... The current LOCALS| ... ... to be initialised from the data stack. ... local buffers are much faster than using ALLOCATE ... The following syntax for local arguments and local variables is ...
    (comp.lang.forth)
  • Re: Eval needs explicit self for accessor methods?
    ... locals declaration causes unexpected behavior: ... Local variables *created* inside a block are *not* visible outside the block. ... The third rule is the one that throws everyone because most programmers tend to think of block arguments as formal arguments that shadow any similarly named variables outside the block but this is incorrect (in Ruby). ... Block arguments behave like *local* variables so if a block argument has the same name as a variable in the enclosing scope then a new local variable is *not* created. ...
    (comp.lang.ruby)