blocks|key|3256873|text|例外真的应该是例外的情况。空指针可能不是程序员的错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3256874|你引用了现有的合同。如果您决定违背约定，毕竟每个Java开发人员都希望equals返回false，那么您将做一些意想不到的、不受欢迎的事情，这将使您的类成为弃儿。|3256875|我完全不同意。我不会为了总是抛出异常而重写equals。如果我是它的客户，我会替换任何这样做的类。|3256876|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

An exception really should be an exceptional situation. A null pointer might not be a programmer error. 

You quoted the existing contract. If you decide to go against convention, after all this time, when every Java developer expects equals to return false, you'll be doing something unexpected and unwelcome that will make your class a pariah.

I could't disagree more. I would not rewrite equals to throw an exception all the time. I'd replace any class that did that if I were its client.

blocks|key|3256902|text|就我个人而言，我更希望它能像现在这样运行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3256903|NullPointerException确定问题出在正在对其执行等于操作的对象中。|offset|length|style|CODE|3256904|如果NullPointerException是按照您的建议使用的，并且您尝试了(某种毫无意义的)操作...|3256905|o1.equals(o1)+where+o1=+null...抛出NullPointerException是因为您的比较函数出错了，还是因为o1为null但您没有意识到？我知道这是一个极端的例子，但根据目前的行为，我觉得你可以很容易地说出问题出在哪里。|3256906|entityMap^0|0|0|K|0|2|K|0|0|D|X|K|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|M|$]]

Personally, I'd rather it perform as it does.

The <code>NullPointerException</code> identifies that the problem is in the object against which the equals operation is being performed.

If the <code>NullPointerException</code> was used as you suggest and you tried the (sort of pointless) operation of...

<code>o1.equals(o1)</code> where o1= null...
Is the <code>NullPointerException</code> thrown because your comparison function is screwed or because o1 is null but you didn't realise?
An extreme example, I know, but with current behaviour I feel you can tell easily where the problem lies.

blocks|key|3042941|text|这并不是一定要回答你的问题，这只是一个例子，当我发现行为是现在的样子时，它是有用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3042942|private+static+final+String+CONSTANT_STRING+=+"Some+value";
String+text+=+getText();++//+Whatever+getText()+might+be,+possibly+returning+null.|code-block|syntax|javascript|3042943|按照现在的情况，我能做到。|3042944|if+(CONSTANT_STRING.equals(text))+{
++++//+do+something.
}|3042945|我也没有机会拿到NullPointerException。如果按照您的建议进行更改，我将不得不重新执行以下操作：|3042946|if+(text+!=+null+&&+text.equals(CONSTANT_STRING))+{
++++//+do+something.
}|3042947|这是一个足够好的理由让行为保持原样吗？我不知道，但这是一个有用的副作用。|3042948|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Not that this is neccessarily an answer to your question, it is just an example of when I find it useful that the behaviour is how it is now.

<pre><code>private static final String CONSTANT_STRING = "Some value";
String text = getText(); // Whatever getText() might be, possibly returning null.
</code></pre>

As it stands I can do.

<pre><code>if (CONSTANT_STRING.equals(text)) {
 // do something.
}
</code></pre>

And I have no chance of getting a NullPointerException. If it were changed as you suggested, I would be back to having to do:

<pre><code>if (text != null &amp;&amp; text.equals(CONSTANT_STRING)) {
 // do something.
}
</code></pre>

Is this a good enough reason for the behaviour to be as it is?? I don't know, but it is a useful side-effect.

blocks|key|308012|text|这是一个棘手的问题。为了向后兼容，你不能这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308013|想象一下下面的场景|308014|void+m+(Object+o)+{
+if+(one.equals+(o))+{}
+else+if+(two.equals+(o))+{}
+else+{}
}|code-block|syntax|javascript|308015|现在将执行with+equals+returning+false+else子句，但不会在抛出异常时执行。|308016|另外，null实际上并不等于说"2“，所以返回false是非常有意义的。那么坚持null.equals("b")返回也是false：)可能会更好|308017|但这一要求确实产生了一种奇怪的、非对称的相等关系。|308018|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

This is a tricky question. For backward compatability you can't do so.

Imagine the following scenario

<pre><code>void m (Object o) {
 if (one.equals (o)) {}
 else if (two.equals (o)) {}
 else {}
}
</code></pre>

Now with equals returning false else clause will get executed, but not when throwing an exception.

Also null is not really equal to say "2" so it makes perfect sense to return false. Then it is probably better to insist null.equals("b") to return also false :))

But this requirement does make a strange and non symmetric equals relation.

blocks|key|3256988|text|我认为这是为了方便，更重要的是一致性-允许空值作为比较的一部分，避免了每次调用equals时进行null检查和实现该检查的语义。null引用在许多集合类型中都是合法的，因此它们可以显示为比较的右侧是有意义的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3256989|使用实例方法进行相等、比较等，必然会使排列不对称-对于多态带来的巨大收益来说，这是一个小麻烦。当我不需要多态性时，我有时会创建一个带有两个参数的对称静态方法，即MyObject.equals(MyObjecta,+MyObject+b)。然后，此方法检查一个参数或两个参数是否为空引用。如果我特别想排除空引用，那么我会创建一个额外的方法，例如equalsStrict()或类似的方法，它会在委托给另一个方法之前执行一个空检查。|3256990|entityMap^0|13|6|1C|4|1S|4|0|28|12|4R|E|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|I|$]]

I think it's about convenience and more importantly consistency - allowing nulls to be part of the comparison avoids having to do a <code>null</code> check and implement the semantics of that each time <code>equals</code> is called. <code>null</code> references are legal in many collection types, so it makes sense they can appear as the right side of the comparison. 

Using instance methods for equality, comparison etc., necessarily makes the arrangement asymmetric - a little hassle for the huge gain of polymorphism. When I don't need polymorphism, I sometimes create a symmetric static method with two arguments, <code>MyObject.equals(MyObjecta, MyObject b)</code>. This method then checks whether one or both arguments are null references. If I specifically want to exclude null references, then I create an additional method e.g. <code>equalsStrict()</code> or similar, that does a null check before delegating to the other method.

blocks|key|3257010|text|请注意，该约定是“对于任何非空引用x”。因此，实现将如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3257011|if+(x+!=+null)+{
++++if+(x.equals(null))+{
++++++++return+false;
++++}
}|code-block|syntax|javascript|3257012|x不需要被视为等于null的null，因为equals的以下定义是可能的：|offset|length|style|CODE|3257013|public+boolean+equals(Object+obj)+{
++++//+...
++++//+If+someMember+is+0+this+object+is+considered+as+equal+to+null.
++++if+(this.someMember+==+0+and+obj+==+null)+{
+++++++++return+true;
++++}
++++return+false;
}|3257014|entityMap^0|0|0|0|1|9|4|E|4|L|6|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]|$I|X|J|Y|K|L]|$I|Z|J|10|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|P|$]]

Note that the contract is "for any non-null reference x". So the implementation will look like:

<pre><code>if (x != null) {
 if (x.equals(null)) {
 return false;
 }
}
</code></pre>

<code>x</code> need not be <code>null</code> to be deemed equal to <code>null</code> because the following definition of <code>equals</code> is possible:

<pre><code>public boolean equals(Object obj) {
 // ...
 // If someMember is 0 this object is considered as equal to null.
 if (this.someMember == 0 and obj == null) {
 return true;
 }
 return false;
}
</code></pre>

blocks|key|3043085|text|在第一种情况下，o1.equals(o2)返回false，因为o1不等于o2，这是非常好的。在第二种情况下，它抛出NullPointerException，因为o2是null。不能在null上调用任何方法。一般来说，这可能是编程语言的一个局限性，但我们必须接受它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3043086|抛出NullPointerException也不是一个好主意，因为它违反了equals方法的约定，并使事情变得更加复杂。|3043087|entityMap^0|8|D|V|2|10|2|1L|K|28|2|2B|4|2J|4|0|2|K|11|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|I|$]]

In the first case <code>o1.equals(o2)</code> returns false because <code>o1</code> is not equal to <code>o2</code>, which is perfectly fine. In the second case, it throws <code>NullPointerException</code> because <code>o2</code> is <code>null</code>. One cannot call any method on a <code>null</code>. It may be a limitation of programming languages in general, but we have to live with it.

It is also not a good idea to throw <code>NullPointerException</code> you are violating the contract for the <code>equals</code> method and making things more complex than it has to be.

blocks|key|3043126|text|在许多常见的情况下，null不会以任何方式异常，例如，它可能只是表示键没有值的(非异常)情况，或者表示“无”。因此，使用未知的y执行x.equals(y)也是很常见的，并且必须始终首先检查null将是徒劳的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3043127|至于为什么null.equals(y)是不同的，在Java语言中对空引用调用任何实例方法都是一个编程错误，因此值得出现异常。应该选择x.equals(y)中x和y的顺序，以便已知x不是null。我会争辩说，在几乎所有的情况下，这种重新排序都可以基于预先知道的对象(例如，从它们的来源，或者通过检查null中的其他方法调用)。|3043128|同时，如果两个对象都是未知的“空值”，那么其他代码几乎肯定需要检查其中至少一个，或者可以在不冒NullPointerException风险的情况下对对象做很多事情。|3043129|由于它是以这种方式指定的，因此破坏约定并为equals的null参数引发异常是一个编程错误。如果您考虑另一种要求抛出异常的方法，那么equals的每个实现都必须对其进行特例处理，并且每次调用具有任何潜在null对象的equals时都必须在调用之前进行检查。|3043130|它可以用不同的方式指定(即，equals的前提条件要求参数是非null的)，所以这并不是说您的论证是无效的，但当前的规范使编程语言更简单、更实用。|3043131|entityMap^0|A|4|1R|1|1U|B|2M|4|0|5|E|1U|B|26|1|28|1|2H|1|2K|4|44|4|0|1B|K|0|L|6|S|4|1U|6|2T|4|30|6|0|E|6|V|4|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1D|8|@$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1R|8|@$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]]|O|$]]

There are many common situations where <code>null</code> is not in any way exceptional, e.g. it may simply represent the (non-exceptional) case where a key has no value, or otherwise stand for “nothing”. Hence, doing <code>x.equals(y)</code> with an unknown <code>y</code> is also quite common, and having to always check for <code>null</code> first would be just wasted effort.

As for why <code>null.equals(y)</code> is different, it is a programming error to call any instance method on a null reference in Java, and therefore worthy of an exception. The ordering of <code>x</code> and <code>y</code> in <code>x.equals(y)</code> should be chosen such that <code>x</code> is known to not be <code>null</code>. I would argue that in almost all cases this reordering can be done based on what is known about the objects beforehand (e.g., from their origin, or by checking against <code>null</code> for other method calls).

Meanwhile if both objects are of unknown “nullness”, then other code almost certainly requires checking at least one of them, or not much can be done with the object without risking the <code>NullPointerException</code>.

And since this is the way it is specified, it is a programming error to break the contract and raise an exception for a <code>null</code> argument to <code>equals</code>. And if you consider the alternative of requiring an exception to be thrown, then every implementation of <code>equals</code> would have to make a special case of it, and every call to <code>equals</code> with any potentially <code>null</code> object would have to check before calling.

It could have been specified differently (i.e., the precondition of <code>equals</code> would require the argument to be non-<code>null</code>), so this is not to say that your argumentation is invalid, but the current specification makes for a simpler and more practical programming language.

blocks|key|308107|text|关于这种不对称性是否不一致的问题，我认为不是，我建议你参考这个古老的禅宗kōan：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308108|308109|问任何一个人他是否和下一个人一样好，每个人都会说是。|unordered-list-item|308110|问任何人他是否和任何人一样好，每个人都会说不。|308111|问任何人他是否和任何人一样好，你永远不会得到回答。|308112|308113|在那一刻，编译器得到了启蒙。|308114|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

To the question of whether this asymmetry is inconsistent, I think not, and I refer you to this ancient Zen kōan:

<ul>
<li>Ask any man if he's as good as the next man and each will say yes. </li>
<li>Ask any man if he's as good as nobody and each will say no.</li>
<li>Ask nobody if it's as good as any man and you'll never get a reply.</li>
</ul>

At that moment, the compiler reached enlightenment.

blocks|key|3043193|text|想想.equals与==的关系，以及.compareTo与比较运算符>、<、>=、<=的关系。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3043194|如果你认为使用.equals比较一个对象和null应该抛出一个NPE，那么你不得不说这段代码也应该抛出一个NPE：|3043195|Object+o1+=+new+Object();
Object+o2+=+null;
boolean+b+=+(o1+==+o2);+//+should+throw+NPE+here!|code-block|syntax|javascript|3043196|o1.equals(o2)和o2.equals(+o1+)之间的区别在于，在第一种情况下，您将某些内容与null进行比较，类似于o1+==+o2，而在第二种情况下，equals方法实际上从未执行过，因此根本不会进行比较。|3043197|关于.compareTo约定，将非空对象与空对象进行比较就像尝试这样做：|3043198|int+j+=+0;
if(j+>+null)+{+
+++...+
}|3043199|显然这是不能编译的。您可以使用自动拆箱来编译它，但在进行比较时会得到NPE，这与.compareTo合同一致：|3043200|Integer+i+=+null;
int+j+=+0;
if(j+>+i)+{+//+NPE
+++...+
}|3043201|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|Z|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Think of how .equals is related to == and .compareTo is related to the comparison operators >, &lt;, >=, &lt;=.

If you're going to argue that using .equals to compare an object to null should throw a NPE, then you'd have to say that this code should throw one as well:

<pre><code>Object o1 = new Object();
Object o2 = null;
boolean b = (o1 == o2); // should throw NPE here!
</code></pre>

The difference between o1.equals(o2) and o2.equals(o1) is that in the first case you're comparing something to null, similar to o1 == o2, while in the second case, the equals method is never actually executed so there's no comparison happening at all.

Regarding the .compareTo contract, comparing a non-null object with a null object is like trying do this:

<pre><code>int j = 0;
if(j &gt; null) { 
 ... 
}
</code></pre>

Obviously this won't compile. You can use auto-unboxing to make it compile, but you get a NPE when you do the comparison, which is consistent with the .compareTo contract:

<pre><code>Integer i = null;
int j = 0;
if(j &gt; i) { // NPE
 ... 
}
</code></pre>

blocks|key|310172|text|如果你考虑到面向对象的概念，并考虑整个发送者和接收者的角色，我会说行为是方便的。在第一种情况下，你是在问一个对象，他是否等于任何人。他应该说“不，我不是”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|310173|在第二种情况下，你没有引用任何人，所以你实际上并没有问任何人。这应该抛出一个异常，第一种情况不应该抛出异常。|310174|我认为只有当你忘记面向对象，把表达式当做一个数学等式来处理时，它才是不对称的。然而，在这个范例中，两端扮演不同的角色，因此可以预期顺序很重要。|310175|最后一点。当你的代码中有错误时，应该引发一个空指针异常。然而，询问一个对象是否无名小卒，不应该被认为是一个编程缺陷。我认为如果一个对象不为null，那么询问它是完全可以的。如果您不能控制为您提供对象的源，该怎么办？而这个源会向你发送null。您是否会检查对象是否为空，然后才会查看它们是否相等？只比较这两个对象不是更直观吗?无论第二个对象是什么，比较都会毫无例外地进行。|310176|老实说，如果在其主体中的equals方法故意返回空指针异常，我会很生气。Equals是针对任何类型的对象使用的，所以它不应该对它接收的内容如此挑剔。如果equals方法返回npe，我脑海中的最后一件事就是它是故意这么做的。特别是考虑到这是一个未检查的异常。如果您确实引发了一个npe，那么一个家伙将不得不记住在调用您的方法之前总是检查null，或者更糟糕的是，将对equals的调用包含在try/catch块(天哪，我讨厌try/catch块)中，但是哦，好吧……|310177|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

If you take object oriented concepts into account, and consider the whole sender and receiver roles, I'd say that behaviour is convenient. See in the first case you're asking an object if he is equal to nobody. He SHOULD say "NO, I'm not".

In the second case though, you don't have a reference to anyone So you aren't really asking anyone. THIS should throw an exception, the first case shouldn't.

I think it's only asymmetric if you kind of forget about object orientation and treat the expression as a mathematical equality. However, in this paradigm both ends play different roles, so it is to be expected that order matters.

As one final point. A null pointer exception should be raised when there's an error in your code. However, Asking an object if he is nobody, shouldn't be considered a programming flaw. I think it's perfectly ok to ask an object if he isn't null. What if you don't control the source that provides you with the object? and this source sends you null. Would you check if the object is null and only afterwards see if they are equals? Wouldn't it be more intuitive to just compare the two and whatever the second object is the comparison will be carried out without exceptions? 

In all honesty, I would be pissed if an equals method within its body returns a null pointer exception on purpose. Equals is meant to be used against any sort of object, so it shouldn't be so picky on what it receives. If an equals method returned npe, the last thing on my mind would be that it did that on purpose. Specially considering it's an unchecked exception. IF you did raise an npe a guy would have to remember to always check for null before calling your method, or even worse, surround the call to equals in a try/catch block (God I hate try/catch blocks) But oh well...

blocks|key|310179|text|如果参数为null，则应返回false。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|310180|要显示这是标准，请参见'Objects.equals(Object,+Object)+from+java.util，它仅对第一个参数(将调用equals(Object)+)执行非对称null检查。来自OpenJDK+SE+11源代码(SE+1.7包含完全相同的内容)：|310181|public+static+boolean+equals(Object+a,+Object+b)+{
++++return+(a+==+b)+%7C%7C+(a+!=+null+&&+a.equals(b));
}|code-block|syntax|javascript|310182|这也会将两个null值视为相等。|310183|entityMap^0|5|4|E|5|0|C|U|1C|9|1Y|E|0|0|6|4|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|P|$]]

You should return <code>false</code> if the parameter is <code>null</code>.
To show that this is the standard, see '<code>Objects.equals(Object, Object)</code> from <code>java.util</code>, that performs an assymetric null check on the first parameter only (on which <code>equals(Object)</code> will be called). From the OpenJDK SE 11 source code (SE 1.7 contains exactly the same):
<pre class="lang-java prettyprint-override"><code>public static boolean equals(Object a, Object b) {
 return (a == b) || (a != null &amp;&amp; a.equals(b));
}
</code></pre>
This also handles two <code>null</code> values as equal.

The contract of <a href="http://java.sun.com/javase/6/docs/api/java/lang/Object.html#equals%28java.lang.Object%29" rel="noreferrer"><code>equals</code></a> with regards to <code>null</code>, is as follows:
<blockquote>
For any non-null reference value <code>x</code>, <code>x.equals(null)</code> should <code>return false</code>.
</blockquote>
This is rather peculiar, because if <code>o1 != null</code> and <code>o2 == null</code>, then we have:
<pre><code>o1.equals(o2) // returns false
o2.equals(o1) // throws NullPointerException
</code></pre>
The fact that <code>o2.equals(o1) throws NullPointerException</code> 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 <code>o1.equals(o2)</code>, which would just &quot;silently fail&quot; instead.
So the questions are:
<ul>
<li>Why is it a good idea that <code>o1.equals(o2)</code> should <code>return false</code> instead of throwing <code>NullPointerException</code>?</li>
<li>Would it be a bad idea if wherever possible we rewrite the contract so that <code>anyObject.equals(null)</code> always throw <code>NullPointerException</code> instead?</li>
</ul>
<hr />
<h3>On comparison with <code>Comparable</code></h3>
In contrast, this is what the <a href="http://java.sun.com/javase/6/docs/api/java/lang/Comparable.html" rel="noreferrer"><code>Comparable</code> contract</a> says:
<blockquote>
Note that <code>null</code> is not an instance of any class, and <code>e.compareTo(null)</code> should throw a <code>NullPointerException</code> even though <code>e.equals(null)</code> returns <code>false</code>.
</blockquote>
If <code>NullPointerException</code> is appropriate for <code>compareTo</code>, why isn't it for <code>equals</code>?
<h3>Related questions</h3>
<ul>
<li><a href="https://stackoverflow.com/questions/2858628/comparable-and-comparator-contract-with-regards-to-null">Comparable and Comparator contract with regards to null</a></li>
</ul>
<hr />
<h3>A purely semantical argument</h3>
These are the actual words in the <a href="http://java.sun.com/javase/6/docs/api/java/lang/Object.html#equals%28java.lang.Object%29" rel="noreferrer"><code>Object.equals(Object obj)</code></a> documentation:
<blockquote>
Indicates whether some other object is &quot;equal to&quot; this one.
</blockquote>
And what is an object?
<h3><a href="http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1" rel="noreferrer">JLS 4.3.1 Objects</a></h3>
<blockquote>
An object is a class instance or an array.
The reference values (often just references) are pointers to these objects, and a special <code>null</code> reference, which refers to no object.
</blockquote>
My argument from this angle is really simple.
<ul>
<li><code>equals</code> tests whether some other object is &quot;equal to&quot; <code>this</code></li>
<li><code>null</code> reference gives no other object for the test</li>
<li>Therefore, <code>equals(null)</code> should throw <code>NullPointerException</code></li>
</ul>

Is it a bad idea if equals(null) throws NullPointerException instead?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

与null相关的合同如下：对于任何非空的引用值x，x.equals(null)应为return false。这是相当奇怪的，因为如果使用o1 != null和o2 == null，那么我们有：o1.equals(o2) // returns falseo2.equals(o1) // throws NullPointe...

问如果equals(null)抛出NullPointerException，这是个坏主意吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如果equals(null)抛出NullPointerException，这是个坏主意吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如果equals(null)抛出NullPointerException，这是个坏主意吗？
EN