null testing

  • Thread starter Dirk Bruere at NeoPax
  • Start date
D

Dirk Bruere at NeoPax

Two lines of code

if ( stationsStr==null || stationsStr.equals(""))

if (stationsStr.equals("") || stationsStr==null)

When stationsStr==null the second line throws exception, but the first
one does not. I assume that in the first line it sees the condition
satisfied and does not test for the second condition. Does this make the
code compiler dependent?

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff
 
J

jnizet

Two lines of code

if ( stationsStr==null || stationsStr.equals(""))

if (stationsStr.equals("") || stationsStr==null)

When stationsStr==null the second line throws exception, but the first
one does not. I assume that in the first line it sees the condition
satisfied and does not test for the second condition. Does this make the
code compiler dependent?

No. It's specified in the JLS. All compilers will ignore the second
test if the first one succeeds.
The same goes for && :
if (stationsStr != null && stationsStr.equals(""))
won't throw an NPE if stationsStr is null.

JB.
 
A

Alan Morgan

Two lines of code

if ( stationsStr==null || stationsStr.equals(""))

if (stationsStr.equals("") || stationsStr==null)

When stationsStr==null the second line throws exception, but the first
one does not. I assume that in the first line it sees the condition
satisfied and does not test for the second condition. Does this make the
code compiler dependent?

Everything is compiler dependent in the sense that any compiler might
compile perfectly correct code incorrectly. However, the above behavior
is well defined. It's known as short-circuit evaluation. The clauses
are evaluated one at a time and as soon as a 'true' is found the evaluation
stops. It works similarly for && as well:

String foo = null
int i = 3;

if (i == 4 && foo.equals("no exception thrown here") {....

i==4 is false, so the whole expression is false, so the call to foo.equals()
isn't made.

Alan
 
D

Dirk Bruere at NeoPax

jnizet said:
No. It's specified in the JLS. All compilers will ignore the second
test if the first one succeeds.
The same goes for && :
if (stationsStr != null && stationsStr.equals(""))
won't throw an NPE if stationsStr is null.

JB.

OK. However, I think I'll test separately anyway so the ordering is
apparent to anyone maintaining the code.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff
 
D

Daniel Pitts

Dirk said:
OK. However, I think I'll test separately anyway so the ordering is
apparent to anyone maintaining the code.
That is often a good idea, but "p != null && p.something" is a common
idiom in many c-descendant languages, so most maintainers will have no
problem with the ordering.

Note: "".equals(null) will *not* throw an NPE, so the order wouldn't
really be that important.

Also, the apache-commons-lang library has a great utils class called
StringUtils, which has very useful methods:
StringUtils.isEmpty(myString), and StringUtils.isBlank(myString) to name
only two. The JavaDocs for each StringUtils methods explain clearly what
the return values are for all the edge and common cases.
 
L

Lew

Dirk said:
OK. However, I think I'll test separately anyway so the ordering is
apparent to anyone maintaining the code.

The order is apparent to anyone maintaining the code if they know
Java. If they don't know Java, then nothing you do, separating the
tests or whatever, will help anyway.
 
R

Roedy Green

if ( stationsStr==null || stationsStr.equals(""))

if (stationsStr.equals("") || stationsStr==null)

When stationsStr==null the second line throws exception, but the first
one does not. I assume that in the first line it sees the condition
satisfied and does not test for the second condition. Does this make the
code compiler dependent?

see http://mindprod.com/jgloss/mccarthyoroperator.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan
 
D

Dirk Bruere at NeoPax

Lew said:
The order is apparent to anyone maintaining the code if they know
Java. If they don't know Java, then nothing you do, separating the
tests or whatever, will help anyway.

Anyone who is likely to maintain will "half know Java" - like me.
I didn't spot it until it threw an exception because another part of the
code had a bug.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff
 
L

Lew

Dirk Bruere at NeoPax said:
Anyone who is likely to maintain will "half know Java" - like me.
I didn't spot it until it threw an exception because another part of the
code had a bug.

Knowledge of the operators is fundamental to the use of Java, and as
pointed out upthread, short-circuit evaluation of && and || is
universal in the C language family. You did the right thing to get
clear on this matter. You should assume, or rather require that
anyone maintaining the code be at least this familiar with Java.

As Eric Sosman pointed out, anyone not at least this familiar with
Java will cause much more serious problems. Knowing how && and ||
work, and how they differ from & and | respectively, is far below the
minimum to consider oneself competent in Java.

With the abundance of tutorials, introductory material, web sites, and
the JLS itself available to the practitioner for free, there's no
reason not to know that much and far more.
 
D

Dirk Bruere at NeoPax

Lew said:
Knowledge of the operators is fundamental to the use of Java, and as
pointed out upthread, short-circuit evaluation of && and || is
universal in the C language family. You did the right thing to get
clear on this matter. You should assume, or rather require that
anyone maintaining the code be at least this familiar with Java.

As Eric Sosman pointed out, anyone not at least this familiar with
Java will cause much more serious problems. Knowing how && and ||
work, and how they differ from & and | respectively, is far below the
minimum to consider oneself competent in Java.

With the abundance of tutorials, introductory material, web sites, and
the JLS itself available to the practitioner for free, there's no
reason not to know that much and far more.

True, but after I have familiarised myself with the 4600 Java classes I
will have died from old age. I have found the best way of learning is doing.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff
 
L

Lew

Dirk said:
True, but after I have familiarised myself with the 4600 Java classes I
will have died from old age. I have found the best way of learning is doing.

Excuses.

First of all, the operators are not part of "the 4600 Java classes",
they're part of the language itself. There's no excuse for not
knowing the core language - there just isn't, at least not after a
couple or few weeks of study. Whining about the API as an excuse not
to know the language is simply pathetic.

Second, just because you don't expect to know the entire API cold
doesn't mean you should avoid studying it. On the contrary, as you
grow and develop your skills, ongoing study of the API rewards you big
time. Constant study is a part of this business.

After a while you get in the habit of figuring there's probably an API
class that will do some or most of what you need for any given
scenario, and you'll hunt through those "4600 Java classes" before re-
inventing the wheel. If the java and javax packages don't have what
you want, you'll get in the habit of looking through Apache Commons or
the like (so "4600" isn't even the limit - it's actually much, much
higher). As pointed out upthread, Apache commons-lang actually has
methods relevant to the original problem in this thread.

Third, doing without knowing is a recipe for doom. You can perform a
drunkard's walk through the body of knowledge for Java programming,
and if you are very, very lucky you will know a tiny fraction of what
you need by the time you've "died from old age". It's extremely
inefficient. Aggressive, directed study of the basics and beyond will
gain you much more knowledge in much less time. As I mentioned
before, you have the JLS itself available for free, through which you
really must read at least twice in its entirety and to which you
should refer often. Read the tutorials - I've been programming in
Java professionally for over ten years and I still read and reread the
tutorials. Spend time on
<http://java.sun.com/>
and <http://www.ibm.com/developerworks/java/>
and <http://www.javapassion.com/>
and <http://www.mindprod.com/jgloss/jgloss.html>
and such. Measure twice, cut once. Don't deliberately keep yourself
in ignorance.

Fourth, read and study the key books, such as /Effective Java/ by
Joshua Bloch and /Java Concurrency in Practice/ by Brian Goetz, et al.

A mentor once told me that if a developer (or any I.T. professional)
doesn't spend at least 20% over and above their work time in study,
that they're slipping behind. This is wisdom.

Doing is an adjunct to study, not an effective replacement for it, if
you are committed to producing good, solid, bug-free, effective code.
Programming is not for the intellectually lazy. Knowledge is power;
in particular, it conveys a competitive advantage.
 
J

Joshua Cranmer

Dirk said:
Two lines of code

if ( stationsStr==null || stationsStr.equals(""))

if (stationsStr.equals("") || stationsStr==null)

When stationsStr==null the second line throws exception, but the first
one does not. I assume that in the first line it sees the condition
satisfied and does not test for the second condition. Does this make the
code compiler dependent?

Welcome to the short-circuit operators, || and &&. The short-circuit or
only evaluates the rhs if the lhs is false, and short-circuit and only
evaluates the rhs if the lhs is true.

This is not a feature unique to Java; C and all of its derivatives (that
I know of) also has this feature. I think the only languages without
such operators are FORTRAN and BASIC.
 
A

Arne Vajhøj

Dirk said:
Anyone who is likely to maintain will "half know Java" - like me.
I didn't spot it until it threw an exception because another part of the
code had a bug.

I think your company could save a ton of money by investing
more money in one of their most important assets: their
employees.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Official Java Classes 10
Can an Applet beep? 4
Free keyboard applet 5
Accessing static field 21
Sorting a JList 4
File over network timeout 3
Change character in string 105
ListModel name 10

Members online

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,276
Latest member
Sawatmakal

Latest Threads

Top