I've encountered a strange situation in Eclipse today, but I'll ask this here first to see if I'm not missing anything. If it's not a bug in Eclipse, it's most certainly a basic question
Now although database is set to point to an existing object in the very first line of the try block, and is never set to null afterwards, Eclipse keeps telling me that, if an IOException occurs, database will always be null. Yet the only code that can throw an IOException occurs either before the try-catch-finally block (and therefore will not be caught), or inside the try block after giving database a non-null value.
So if I'm right, if an IOException is caught, database will never be null, not always. So can anyone confirm this as a bug in Eclipse, or am I just missing something?
What do you mean by "according to Eclipse, database is always null"?
Do you mean that whenever you run this code in Eclipse then
always returns false? That wouldn't have anything to do with Eclipse, and would have everything to do with the JRE - but is probably a mistake on your part for which we would need more code (like the getDatabaseConnection() method -> signature and all).
I'm with Steve on this - a little more information is required.
Just copying your code into Eclipse (Europa) on my Mac gave me zero warnings and zero errors.
FindBugs only reported warnings on my helper code that I needed in order to compile your code. :roll:
PMD gave the usual warnings that are neither here nor there:
is, zis, & table could all be declared final (not much value IMHO)
avoid short names like "is"
avoid assignments in operands [while ((entry = zis.getNextEntry()) != null)]
String.toLowerCase should use a locale
Nothing extrordinary in any of that (it also complained about all my helper classes & methods - nice to know I am consistent )
BTW: My helper classes & methods were:So in my case I did not have Eclipse complain about database being null in any of it's uses. Perhaps you are running a different lint program that might be giving you that warning/error?
Oh - and if I actually tried to run this, I would expect to have a null pointer exception, since my mocked getDatabaseConnection() method does return null!
Andrew: I wrote that method myself, and it can really only throw SQLException. Its signature:
And like I said, the code can never return null. It returns a reference to my database connection which it will create and open if necessary.
The exact message my Eclipse (Ganymedes, 3.4) is giving me:
Null comparison always yields false: The variable database can only be null at this location
But as far as I can tell, database will never be null at that point. Or even if my method could return null, it would not ensure that database will always be null (as Eclipse is claiming) - it could be either null or non-null, and the check would be necessary. [ August 17, 2008: Message edited by: Rob Prime ]
Okay, that is a configuration in Eclipse, and it should be a Warning (or ignored), not an Error. If it is appearing as an Error (light-bulb with a red X) then you mis-configured Eclipse.
Go to the Project -> Properties -> Java Compiler -> Error / Warnings. Expand the section for Unnecessary code and change "Redundant null checks" from Error to either Warning or Ignore.
Is this a bug? No, not really. Eclipse know that you set the reference to null before the block with the error message would execute but can't follow all the possible paths for code execution to determine that the value will not be null when it gets to the marked line.
So normally, if you use the "Redundant null checks" option it would be a warning so you as the programmer can decide if the check is null or not. Setting it as an Error is a configuration mistake.
I have it as a warning, but I strive to remove all warnings from my code as well. This is the only one left in all code I've checked since upgrading to 3.4, and that was quite a bit. (Although I am suppressing a few deprecation and unchecked warnings, but the former only in deprecated code and the latter only if I know for certain it's OK to suppress it).
I understand what you say about Eclipse not being able to follow all the paths. But then why can't it accept that database might be (and in fact, will be) non-null? All it is saying is that database is 100,00% certain to be null at that point, which I refuse to believe.
Unless somebody can prove me wrong (which is why I started this thread), I will consider this an Eclipse bug which I will then report to the Eclipse team.
If it helps any, IntelliJ IDEA's "always null / never null" inspection does not post any warnings with the code you posted. In fact, if I annotate the getDatabase method with a @NotNull annotation (indicating that the method is guaranteed not to return null), IDEA gives me the opposite warning indicating that the database can never be null for the line in question (i.e. the if statement in the IOException catch block).