Re: "final" bug??
Eric Sosman wrote:
Roedy Green wrote:
Consider the following code
static final String allpads;
static
{
try
{
allPads = HunkIO.readEntireFile( ALLPADS_FILE );
}
catch ( IOException e )
{
err.println( "Unable to access allPads.pad" );
allPads = null;
}
}
According to the IntelliJ inspector, this allPads should be final.
But according to Javac, it should not, claiming I might be trying to
redefine a final.
Which is correct and why?
There's probably something in the JLS, if you feel like
playing Language Lawyer (or at least Language Law Clerk) for
a while. I'd probably just dodge the issue and write
static {
String s = null;
try {
s = HunkIO.readEntireFile( ALLPADS_FILE );
catch (IOException e) {
err.println("Unable to access allPads.pad");
}
allPads = s;
}
Aside: The error message would be more helpful if it
didn't lose the information carried in the IOException, and
mightn't "allPads.pad" be better as ALLPADS_FILE?
Great minds think alike.
I prefer the idiom where the 'String s = null;' is just 'String s;' and the
assignment occurs in both the 'try' and 'catch' blocks. Others prefer
redundant assignment to redundant typing.
I think avoiding redundant typing is somewhat the wrong kind of laziness,
sometimes. In this particular case, the redundant assignment is low overhead,
but one expects it to occur most of the time and therefore to be avoided, but
only at class initialization and therefore who cares, but putting it
separately in the 'catch' block more clearly documents the intent of the logic
than the redundant assignment does, so I care.
--
Lew