The contract of equals
with regards to null
, is as follows:
For any non-null reference value
x
,x.equals(null)
shouldreturn false
.
This is rather peculiar, because if o1 != null
and o2 == null
, then we have:
o1.equals(o2) // returns false
o2.equals(o1) // throws NullPointerException
The fact that o2.equals(o1) throws NullPointerException
is a good thing, because it alerts us of programmer error. And yet, that error would not be catched if for various reasons we just switched it around to o1.equals(o2)
, which would just "silently fail" instead.
So the questions are:
o1.equals(o2)
should return false
instead of throwing NullPointerException
?anyObject.equals(null)
always throw NullPointerException
instead?Comparable
In contrast, this is what the Comparable
contract says:
Note that
null
is not an instance of any class, ande.compareTo(null)
should throw aNullPointerException
even thoughe.equals(null)
returnsfalse
.
If NullPointerException
is appropriate for compareTo
, why isn't it for equals
?
These are the actual words in the Object.equals(Object obj)
documentation:
Indicates whether some other object is "equal to" this one.
And what is an object?
An object is a class instance or an array.
The reference values (often just references) are pointers to these objects, and a special
null
reference, which refers to no object.
My argument from this angle is really simple.
equals
tests whether some other object is "equal to" this
null
reference gives no other object for the testequals(null)
should throw NullPointerException
To the question of whether this asymmetry is inconsistent, I think not, and I refer you to this ancient Zen kōan:
At that moment, the compiler reached enlightenment.