views:

260

answers:

4

In java, Does the following line have a possibility (even 0.01%) to throw a NullPointerException??

public static void handleRequest(String str1){
   if (str1 == null){  // this line throws NPE, how come !! is it a JDK1.5 bug!!
        return null;
   }
   // other staff
}

Actually I am falling some bug in the code and It says that the exact above line in the method throws a java.lang.NullPointerException ?!

+10  A: 
if (str1 == null)  

will not throw a NullPointerException.

if(str1.equals(null)) 

does have that possibility.

EDIT:

If the line above is referenced by your stack trace, there is a very real chance that the code you are running does not match the code that you are looking at. This could happen if you made modifications to the class after you compiled and deployed it, resulting in mis-matched line numbers.

akf
Actually, `if(str1.equals(null))` either throws a NullPointerException, either return false. So, you will never want to write that (except if the null arg is not literal).
leonbloy
I agree that it doesn't make much sense to have that line, but that doesnt preclude it from showing up in someone's code.
akf
Yes, as a teaching assistant I saw this very often in students' code, probably the second most common mistake for that 300-level class (#1 was forgetting `implements Serialized`!)
BlueRaja - Danny Pflughoeft
+18  A: 

No, that line won't throw a NullPointerException under any circumstances.

But it depends what you mean by "similar". For example, if your actual line of code is

if (foo.str1 == null)

then you'll get a NullPointerException if foo is null.

Etaoin
I help a lot of people debug. Sometimes they ask/hint at asking why I'm differently abled, sometimes they just are glad to be past a roadblock. But if they give me an opening (or I'm tired of helping them), I point out the axiom I'm using:*If everything you know is telling you that the behavior you're seeing can't be right, then "everything you know" can't be right.*Systematically challenge ALL of your assumptions and you'll find your problem a whole lot faster. If your repro case doesn't repro the error, it's not a repro case. Copy more code. Improve the simulation. Delve deeper.
Jason
+4  A: 

No,

if (str1 == null)

cannot throw a null pointer exception as no pointer is dereferenced.

The similar

if (obj1.getStr1() == null)

can throw a NPE in the case that obj1 == null, or,

if (str1 == null && str1.length() == 0)

will throw a NPE on str1.length() when str1 == null. (In this case the || operator should have been used.)

Can you show the exact line on which it breaks and include the stacktrace?

rsp
+2  A: 

If you have byte code manipulation, e.g. in OSGi components the field access can be replaced with proxied getter methods. If you access a field after the underlying component has been discarded, the fields access throws an NPE because it has been replaced with the following and the thisObject is set to null.

if (thisObject.getStr1() == null)

BTW: I had a bug relating to this very problem today. :P

Peter Lawrey
but shouldn't this access have happened before this line of code, considering the code is checking a method parameter against null, wouldn't your proxied getter methods have been used before the call to the method and thus crash there, and not on the indicated line?
Lasse V. Karlsen
Code injection changes teh byte code, not the source. It doesn't insert new lines of code so when it reports a failure it is on that line.
Peter Lawrey