!s.equals("") returns nullPointerException ???

[Tom]

Hi,

I have

String s="";
if (!s.equals("")) {

// do some stuff
}

I have that within a try{} block and I get a nullPointerException if I run
that.... However if check if s!="" then it works OK.... I don't get it. I
also tried if (!s.length()!=0) ... and the same thing... Any ideas??? I've
pulled to many hairs today.

-Tom

 

[Tom]

ok forget it my string s was actually null so i was calling .equals on a
null object. ok makes sense. i was under the impression that
req.getParameter() would return "" instead of null. nope. my wrong
assumption.

-Tom

 

[Roedy Green]

I have that within a try{} block and I get a nullPointerException if I run
that.... However if check if s!="" then it works OK.... I don't get it.

s.equals(t)

s Must not be null for this to work. You need an object to find the
equals method.
t may be null.

s == t
either s or t can be null and it will still work. You are just
comparing references. You don't need an object since you are not
invoking any methods.


See http://mindprod.com/jgloss/gotchas.html#STRINGCOMPARISON

 

[xarax]

Hi,

I have

String s="";
if (!s.equals("")) {

// do some stuff
}

I have that within a try{} block and I get a nullPointerException if I run
that.... However if check if s!="" then it works OK.... I don't get it. I
also tried if (!s.length()!=0) ... and the same thing... Any ideas??? I've
pulled to many hairs today.

-Tom

You posted pseudo-code. It should work just fine as posted,
but I suspect that is not what you are using.

String s = "";

if(! "".equals(s) )
{
// stuff
}

would be safer way to compare a known String with
a variable that may have a null value.

 

[Jayaram]

Could you elaborate on what you are doing within and after the 'if {}' clause ?

 

[Jon A. Cruz]

I'm interested in Xarax's suggestion though, of checking if(!"".equals(s))
... will this return an exception of s is null? I guess you are no longer
calling a method on an object which is null... I never thought of that way
of checking for null or "".

It will return false if s is null. It's a very nice solution, since it
leverages the fact that in Java, all String literals are actually object
instances.

Of course, if you want to ensure you have both non-null and non-empty,
then the code changes to

if ( s != null && !"".equals(s) )

 

[Tom]

Of course, if you want to ensure you have both non-null and non-empty,

then the code changes to

if ( s != null && !"".equals(s) )

....but if !"".equals(s) return false if s is null then why would you need to
check if s is null?

-Tom

 

[Drew Volpe]

s.equals(t)

s Must not be null for this to work. You need an object to find the
equals method.
t may be null.

this is why it's often better to write:

"".equals(myString);






dv

--------------------------------------------------------------------------
The geographical center of Boston is in Roxbury. Due north of the
center we find the South End. This is not to be confused with South
Boston which lies directly east from the South End. North of the South
End is East Boston and southwest of East Boston is the North End.

Drew Volpe, mylastname at hcs o harvard o edu

 

[Tim Tyler]

:> Of course, if you want to ensure you have both non-null and non-empty,
:> then the code changes to
:>
:> if ( s != null && !"".equals(s) )

: ...but if !"".equals(s) return false if s is null then why would you need to
: check if s is null?

It doesn't.

"".equals(null) returns false;

!"".equals(null) returns true.

 

[Chris Smith]

...but if !"".equals(s) return false if s is null then why would you need to
check if s is null?

Because you probably don't want a null reference to fall into the same
case as a reference to a non-empty String.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Because it's not almost certaintly wrong. Often null String variables
are expected and perfectly valid.

<sigh> That's not the issue. Of course reference variables can often
be null. The issue is how often you find yourself with two very
specific cases in the logic of your code, those being:

1. String reference is null, or points to a non-empty String.
2. String reference points to an empty String.

[Of course, the literal could be other than the empty String, but I'm
going to assume for the purpose of this discussion that it's the empty
String, because that seems the most likely in a class of unlikely
scenarios.]

And furthermore, the question is whether this situation is enough of the
norm that it's worth recommending a language usage that encodes this as
a general preference, in the way that you did. The problem that this
solves is, in fact, so unique that I'd probably avoid a concise-looking
expression that doesn't deal with the odd intricacies of the desired
logic, and instead write the statement as:

if ((myString == null) || !myString.equals(""))
{
// CASE 1
}
else
{
// CASE 2
}

If you very frequently run into this specific situation, where a null
reference should be treated the same as a non-empty String, but
differently from an empty String, I'm really curious about where it pops
up so frequently. In the mean time, I'm concerned that recommendations
for the "literal".equals(variable) style will be picked up by those who
aren't thinking about the possibility of a null reference, and they will
write code that produces more logic errors and fewer clear and helpful
runtime errors. Those who are already thinking about null references
and considering them as possible inputs are probably competent enough to
express their logic on their own.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[soft-eng]

Except that they do different things:

Yes, of course, you have to know what you want to happen
with null, and explicit writing it out makes sure
that you do know it, as does any reader of your code.

Usually, if I am checking for "", I would many times
want the same thing for null (for instance when
checking for the presence of a parameter.) That's
when an automatic

"".equals(s)

would actually 'work' with null, but result
in a wrong choice in case a null does happen
to come along.

Actually, an expanded form would be one of:

(s == null) || !s.equals("")
(s != null) && s.equals("")

?? Why would it be restricted to that? What if I want to make sure s is
neither null nor an empty string?

 

[Chris Smith]

I'm not sure what direction you're going...

Usually, if I am checking for "", I would many times
want the same thing for null (for instance when
checking for the presence of a parameter.) That's
when an automatic

"".equals(s)

would actually 'work' with null, but result
in a wrong choice in case a null does happen
to come along.

Right. For some definitions of "work", including only definitions where
your program is broken but doesn't tell you, it would work fine.

?? Why would it be restricted to that? What if I want to make sure s is
neither null nor an empty string?

Because I was talking about expanded forms of "".equals(s) [or its
negation], and your stated requirements don't match that expression. So
I wouldn't consider any correct code to be an expansion of "".equals(s).
That follows by necessity, since "".equals(s) is itself broken.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation