Forums Register Login

Variable is always null - or is it?

+Pie Number of slices to send: Send
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

My code:

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?
+Pie Number of slices to send: Send
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).
+Pie Number of slices to send: Send
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!

    Regards, Andrew
    +Pie Number of slices to send: Send
    Dumb question, but are you sure getDatabaseConnection cannot throw IOException or a subclass of IOException?

    Regards, Andrew
    +Pie Number of slices to send: Send
    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 ]
    +Pie Number of slices to send: Send
    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.
    +Pie Number of slices to send: Send
    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.
    +Pie Number of slices to send: Send
    Rob,

    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).

    I hope that helps.
    +Pie Number of slices to send: Send
    Thanks, I though I was losing my mind. I had been staring at that code for at least 15 minutes, just checking all possibilities to see if it could ever be null.

    Guess it is a bug in Eclipse then.
    +Pie Number of slices to send: Send
    Looked at it some more and fiddled. This looks like a bug in eclipse. The warning seems to relate more to the ZipEntry than to the database reference. For example, if I change the code to:

    (i.e. I make sure the entry isn't unassigned when declared then change the while so it doesn't assign in the condition, but instead assigns at the end of the loop)

    the warning goes away completely.

    The warning seemed to go away whenever the ZipEntry entry; line was assigned to, the above code was just what I came to in order to keep the same functionality.

    So it seems like Eclipse is warning about the wrong reference here.

    The warning still persisted in the SQLException catch block.
    [ August 17, 2008: Message edited by: Steve Luke ]
    +Pie Number of slices to send: Send
    That's strange - I never ever got a warning in the SQLException block.

    Anyway, I also managed to remove the warning by using a nested try block:

    Both catch blocks needed to handle the database rollbacking anyway, and no need to do that if there is no database connection. Also the closing has been separated so nothing can be null now.

    Campbell, if you like, you can move this to IDE's now
    [ August 17, 2008: Message edited by: Rob Prime ]
    The world's cheapest jedi mind trick: "Aw c'mon, why not read this tiny ad?"
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com


    reply
    reply
    This thread has been viewed 3980 times.
    Similar Threads
    which catch start first ?
    zip / pipedinputstream / pipedoutputstream problem
    Finally
    Decompress the HTTP Request body
    Getting info from a file inside an ear/war file.
    More...

    All times above are in ranch (not your local) time.
    The current ranch time is
    Mar 29, 2024 01:05:01.