aString;equals(bString) on null-object

[Patrick Muls]

The aString.equals(bString) method throws a NullPointerException when aString is null. While that is probably the best solution using other objects, I wonder why it is not intercepted for a String object as it is obvious that the intented result is false.

[Gabriel White]

Hey Pat, could you post your code: remember to use the code tags
Thanks
Steve

[Bear Bibeault]

Regardless of what type of object a reference 'points' to, an attempt to dereference a null reference will lead to an NPE. Simply because the reference happens to be to an object of type String makes no difference.
hth,
bear

[Gabriel White]

But if you want our help, we need to see where the NPE is coming from (What method). So we need to see your code.
Peace out

[Joel McNary]

It is true that the .equals method will throw a NPE when the object calling it is null; there is no real way around this (other than modifying the JVM somehow, as I inferr your intent from your post).
However, it is possible (and even preferable) to write your own equals method outside the context of the object (i.e., make it static). E.g:

public static boolean stringEquals(String s1, String s2){
    if(s1 == null && s2 != null || s1 != null && s2 == null){
        return false; // One is null, the other isn't
    }
    else if(s1 == null && s2 == null){
        //Either return true if you think that null == null, 
        //false because you think null != null,
        //or throw an exception stating that you can't
        //compare two nulls.
    }
    else{ // both are valued
        return(s1.equals(s2));
    }
}

[Layne Lund]

Originally posted by Patrick Muls:
The aString.equals(bString) method throws a NullPointerException when aString is null. While that is probably the best solution using other objects, I wonder why it is not intercepted for a String object as it is obvious that the intented result is false.

I would beg to differ. The intended result may be false in your current project, but that doesn't mean it is universally true.
Also, I wonder if equals() throws a NPE if bString is null? If not, you can easily get around the NPE caused when aString is NULL by using the short-cut && operator:

if(aString != null && aString.equals(bString))
{
  // do stuff
}

[Neil Laurance]

And another common code convention is to ensure string literals go first, for example:

String s = mightReturnNull();
if(s.equals("foo")) // could throw NPE
if("foo".equals(s)) // wont throw NPE

Cheers, Neil

[Bear Bibeault]

Also, I wonder if equals() throws a NPE if bString is null?

bString can safely be null. The result of the comparison will be false, but no NPE will be thrown.
hth,
bear

[Patrick Muls]

First thanks to all of you who voiced an answer to my question. Some of you asked for the code. It is part of a large webapplication written by my predecessor now almost 2 years ago, which resulted in the server getting blocked. The only message I got in the log was simply saying there was a NPE, but no trace or anything was available to find it. I didn't even know which user suffered the problem. So I spent several days trying to find it. It turned out to be in an IF statement where about a dozen strings are tested to determine they either all or none of them are filled in. The test was conform to Layne Land's suggestion,
if ((s1 != null && s1.equals(""))
|| (s2 != null && s2.equals("")
etc)
But somewhere in this set, he wrote
|| (sx != null && sy.equals("")
|| (sy != null && sy.equals("")
where in 99.9% of the cases sx and sy are always boh present or not. But in some records sx exists and sy not, and there the NPE was thrown.
So in the future if I have to write such a test, I'll certainly will use Neil's suggestion to put the literal first.
Thanks again to you all.