return aSpecies.compareTo( bSpecies );
Perhaps even pushing the duplicated denullification into a little method.
Note that when the Elvis operator makes it into Java, you will be able to
write:
This whole business of multiple representations for empty.
Acch(Imagine a Yiddish sound of contempt).
null, "", " "
I have have always felt this looseness was like a trap a child digs to
catch the mailman.
There are no assertions defining what a given method parm will accept
(though IntelliJ is pushing @Nullable and #NotNull) There is not even
a JavaDoc convention to warn you if a method might produce which
combinations of the three.
see
http://mindprod.com/jgloss/empty.html
From a machine efficiency point of view, null is probably the best
convention. Empty is usually a special case anyway. It might as well
be easy to detect.
From a coding safety point of view "" is best. It will generaly work
sensibly if passed to a method expecting a substantial string, where
there is a good chance it would fail on null.
Maybe we need some sort of Generics to declare what methods
produce/consume and have thecompiler tell you if you are potentially
doing something dangerous at compile time.
I once drove my boss nearly to distraction, because I was convinced
the problem with the project was random empty string representations.
The DWIM school of thinking
Way back I wrote suggesting a DWIM approach to taming the dreaded
NullPointerException. It is inspired more by scripting languages.
Thing a = null.
a.getAString() --> null
a.getTemp() --> 0.0d;
a.getDufusOBject --> null
a.doSomething() --> does nothing
a.doSomethingElse ( engage( 42 ) ); --> invokes engage function
( in my mind checking a and store come after RHS evaluation,
If I had my way Java would a much stricter left to right
evaluation order)
For more explicit use, you would replace the . operator with .? to
indicate you wanted to do a dummy var fetch/method call or none at all
if "a" were null. When I thought about extending that I though
perhaps classes should use dummy objects in place of null to bypass
this sort of trouble at clealr all that null-handling clutter,just
letting the null-handling logic come out in the wash most of the
time.
The thinking is a bit like the way there are are multiple flavours of
NaN in IEEE floating point, and the value appearing in calculation is
not the end of the world. The null just propagates.
P.S.
Apparently the eponymous Elvis rarely went to Las Vegas. I have not
tracked down who he is. People were often puzzled when I talked about
the McCarthy or operator || the bitwise | one.
see
http://mindprod.com/jgloss/or.html The McCarthy I refer to
probably never met Candice Bergen and died recently.
