Re: equality and null pointers
On Apr 12, 3:26 am, Lew <l...@nospam.lewscanon.com> wrote:
There is no "likely" in Java. There is what it is, and there isn't what it
ain't. One thing it ain't is probabilistic.
Thanks. :-)
[To visionset:]
From what I understand, you're in fact saying, *not* that (null !=
null), but that it's probably not a good idea to use that test in
code, because null is a special value and should be treated as such.
Is that what you're saying?
I see your point, even if I don't think it's a generalizable good
practice rule. For me, null values should generally be documented, and
that's where my personal rules stop. They may be meaningful, and their
comparison too, in many cases.
[back to Lew]
To the OP:
Hi! :-)
You should be range-checking values anyway. It is not redundant to check for
both null and the empty string; they are different values.
If I may say so, you are answering a special case of my question. The
string stuff was an example. In fact, you're more or less saying the
same as visionset: treat the null values as special values, don't
compare them! I agree in some cases (I'm not speaking of those here),
not in all cases.
It's not so bad to write a utility method like the one you showed if you
commonly treat both null and "" as equivalently undesirable. However, the
language itself treats the cases differently because they are.
I'm not blaming the language! Of course it treats them differently...
in fact, it doesn't treat null at all in this case, because
"null.equals(null)" simply throws a null pointer exception (as well it
should). :-)
Here's an example of what I'm saying:
public class MyStuff {
private A a;
private B b;
/* ...many others... */
@Override
public boolean equals(Object obj) {
if (obj == null) {
return false;
}
if (obj == this) {
return true;
}
if (! (obj instanceof EntityAction)) {
return false;
}
MyStuff otherStuff = (MyStuff) obj;
return Utils.areEqual(a, otherStuff.a)
& Utils.areEqual(b, otherStuff.b); // ..and all the other
stuff
}
}
If I wasn't using my utility method, I would simply be copy-pasting
code all around (which is what <CodeFor...@gmail.com> suggested). And
of course, sometimes null values are special, but in the "equals()"
method, I simply want to compare two instances. Let's say it's for the
sake of a collections utility method, searching, sorting etc. I don't
want any checking logic in there, because if there is any null value
management, it should be in the constructor, the setter, the
deserializer or someplace like that. It's not up to the "equals()"
method to refuse / accept null values.
If I may add, if business logic implies that "a" cannot be null, the
code could simply be...
return a.equals(otherStuff.a)
& Utils.areEqual(b, otherStuff.b); // ..and all the other
stuff
I still think I need this method. I'm sure many people need it, and
among those who don't, a lot surely simply forget a couple of
defensive tests or don't mind about code copying (I've come across
both)... which is not *extremely* bad, as I said before it's a minor
point, I've seen worse. :-)
My questions, open as they were, were more about how to best do it and
does it exist... Apparently it doesn't exist in Java utilities. Too
bad. This being said, thanks for the answers!
JR