如果 equals(null) 抛出 NullPointerException 是不是一个坏主意？

Question

的契约equals 对于null，如下：

对于任何非 null 引用值 x，x.equals(null) 应返回 false。

这是相当奇怪的，因为如果 o1 != null 且 o2 == null，那么我们有：

o1.equals(o2) // returns false
o2.equals(o1) // throws NullPointerException

o2.equals(o1) 抛出 NullPointerException< /code> 是一件好事，因为它可以提醒我们程序员的错误。然而，如果由于各种原因我们只是将其切换到 o1.equals(o2)，则不会捕获该错误，这只会“默默地失败”。

所以问题是：

• 为什么 o1.equals(o2) 应该返回 false 而不是抛出 NullPointerException 是个好主意？
• 如果我们尽可能重写合约，以便 anyObject.equals(null) 始终抛出 NullPointerException，这会是一个坏主意吗？

---

与 Comparable

相比，这就是 可比较合同说：

请注意，null 不是任何类的实例，并且 e.compareTo(null) 应该抛出 NullPointerException，即使 >e.equals(null) 返回 false。

如果 NullPointerException 适用于 compareTo，为什么它不适用于 equals？

问题

• 关于null的Comparable和Comparator合约

---

相关 语义参数

这些是 Object.equals(Object obj) 文档：

指示某个其他对象是否“等于”此对象。

什么是对象？

JLS 4.3.1 对象

对象是类实例或数组。

引用值（通常只是引用）是指向这些对象的指针，以及一个特殊的null引用，不引用任何对象。

从这个角度来说我的论证其实很简单。

• equals 测试某个其他对象是否“等于”this
• null 引用不给出其他对象< /em> 用于测试
• 因此，equals(null) 应该抛出 NullPointerException

Answer 1

至于这种不对称性是否不一致的问题，我认为不是，我向您推荐这句古老的禅宗公案：

• 问任何一个人是否与下一个人一样好，每个人都会说是。
• 问任何一个人是否比任何人都优秀，每个人都会说“不”。
• 如果问任何人是否和任何人一样好，你永远不会得到答复。

在那一刻，编译器顿悟了。

Answer 2

异常确实应该是异常情况。空指针可能不是程序员错误。

您引用了现有合同。如果您决定违反惯例，那么经过这么长时间，当每个 Java 开发人员都希望 equals 返回 false 时，您将做一些意想不到的和不受欢迎的事情，这将使您的类成为贱民。

我完全不同意。我不会重写 equals 来一直抛出异常。如果我是它的客户，我会替换任何这样做的类。

Answer 3

想一想 .equals 与 == 的关系，.compareTo 与比较运算符 >、<、>=、<= 的关系。

如果您认为使用 .equals 将对象与 null 进行比较应该抛出 NPE，那么您必须说这段代码也应该抛出一个：

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

o1.equals(o2) 和 o2 之间的差异。 equals(o1) 是，在第一种情况下，您将某些内容与 null 进行比较，类似于 o1 == o2，而在第二种情况下，equals 方法从未实际执行，因此不会发生比较根本不。

关于 .compareTo 契约，将非空对象与空对象进行比较就像尝试这样做：

int j = 0;
if(j > null) { 
   ... 
}

显然这不会编译。你可以使用自动拆箱来使其编译，但是当你进行比较时你会得到一个 NPE，这与 .compareTo 合约一致：

Integer i = null;
int j = 0;
if(j > i) { // NPE
   ... 
}

Answer 4

并不是说这一定是您问题的答案，这只是我发现有用的一个例子，现在的行为是这样的。

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

就目前情况而言，我可以做到。

if (CONSTANT_STRING.equals(text)) {
    // do something.
}

而且我没有机会得到 NullPointerException。如果按照您的建议进行更改，我将不得不重新做：

if (text != null && text.equals(CONSTANT_STRING)) {
    // do something.
}

这是行为如此的充分理由吗？我不知道，但这是一个有用的副作用。

Answer 5

如果您考虑面向对象的概念，并考虑整个发送者和接收者角色，我会说这种行为很方便。在第一种情况下，您询问一个对象是否等于任何人。他应该说“不，我不是”。

但在第二种情况下，你没有参考任何人，所以你并没有真正询问任何人。这应该抛出异常，第一种情况不应该抛出异常。

我认为只有当您忘记面向对象并将表达式视为数学等式时，它才是不对称的。然而，在这个范式中，两端扮演着不同的角色，因此可以预期顺序很重要。

最后一点。当代码中存在错误时，应引发空指针异常。然而，询问一个对象是否无人，不应被视为编程缺陷。我认为询问一个对象是否不为空是完全可以的。如果您不控制为您提供该对象的源怎么办？并且该来源向您发送 null。您会检查对象是否为空，然后再查看它们是否相等吗？只比较两者，无论第二个对象是什么，都会毫无例外地进行比较，这不是更直观吗？

老实说，如果其体内的 equals 方法故意返回空指针异常，我会很生气。 Equals 旨在用于任何类型的对象，因此它不应该对其接收的内容如此挑剔。如果 equals 方法返回 npe，我最不想看到的就是它是故意这样做的。特别考虑到这是一个未经检查的异常。如果你确实提出了一个 npe ，那么一个人必须记住在调用你的方法之前总是检查 null ，或者更糟糕的是，在 try/catch 块中包围对 equals 的调用（上帝我讨厌 try/catch 块）但是哦，好吧。 ..

Answer 6

就我个人而言，我宁愿它像现在这样执行。

NullPointerException 表明问题出在正在执行 equals 操作的对象中。

的（有点无意义的）操作

如果按照您的建议使用了 NullPointerException，并且您尝试了... o1.equals(o1) 其中 o1= null ...
抛出 NullPointerException 是因为您的比较函数被搞砸了，还是因为 o1 为 null 但您没有意识到？
我知道这是一个极端的例子，但根据目前的行为，我觉得你可以很容易地看出问题出在哪里。

Answer 7

在第一种情况下，o1.equals(o2) 返回 false，因为 o1 不等于 o2，这完全没问题。在第二种情况下，它会抛出 NullPointerException，因为 o2 为 null。不能对 null 调用任何方法。一般来说，这可能是编程语言的限制，但我们必须忍受它。

抛出 NullPointerException 也不是一个好主意，因为您违反了 equals 方法的约定，并使事情变得比应有的更加复杂。

Answer 8

在许多常见情况下，null 无论如何都不例外，例如，它可能只是表示键没有值的（非例外）情况，或者代表“无”。因此，使用未知的 y 执行 x.equals(y) 也很常见，并且必须首先检查 null 只是浪费精力。

至于为什么 null.equals(y) 不同，在空引用上调用任何实例方法是一个编程错误在 Java 中，因此值得例外。应选择 x.equals(y) 中 x 和 y 的顺序，以便知道 x不为null。我认为，在几乎所有情况下，这种重新排序都可以根据事先了解的对象来完成（例如，从它们的起源，或者通过检查 null 是否有其他方法调用）。

同时，如果两个对象都具有未知的“空性”，那么其他代码几乎肯定需要检查至少其中一个，或者在不冒 NullPointerException 风险的情况下对该对象做不了太多事情。

由于这是指定的方式，因此违反约定并为 equals 的 null 参数引发异常是一个编程错误。如果您考虑要求抛出异常的替代方案，那么 equals 的每个实现都必须对其进行特殊处理，并且每次对 equals 的调用都带有任何在调用之前必须检查潜在的 null 对象。

它可以以不同的方式指定（即equals的前提条件要求参数非null），所以这不是为了说你的论证无效，但当前的规范使得编程语言更简单、更实用。

Answer 9

请注意，该契约是“对于任何非空引用 x”。因此，实现将如下所示：

if (x != null) {
    if (x.equals(null)) {
        return false;
    }
}

x 不必为 null 即可被视为等于 null，因为 equals 是可能的：

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;
}

Answer 10

我认为这是为了方便，更重要的是一致性 - 允许空值成为比较的一部分，可以避免每次调用 equals 时都必须进行 null 检查并实现其语义。 null 引用在许多集合类型中都是合法的，因此它们可以出现在比较的右侧是有意义的。

使用实例方法进行相等、比较等，必然会使排列不对称——这对于多态性的巨大收益来说有点麻烦。当我不需要多态性时，有时我会创建一个带有两个参数的对称静态方法，MyObject.equals(MyObjecta, MyObject b)。然后，此方法检查一个或两个参数是否为空引用。如果我特别想排除空引用，那么我会创建一个附加方法，例如 equalsStrict() 或类似方法，在委托给其他方法之前执行空检查。

Answer 11

如果参数为 null，则应返回 false。

要表明这是标准，请参阅 java.util 中的“Objects.equals(Object, Object)”，它仅对第一个参数执行不对称 null 检查（在将调用 equals(Object)）。来自 OpenJDK SE 11 源代码（SE 1.7 包含完全相同）：

public static boolean equals(Object a, Object b) {
    return (a == b) || (a != null && a.equals(b));
}

这也将两个 null 值视为相等。

Answer 12

这是一个棘手的问题。为了向后兼容，你不能这样做。

想象一下以下场景，

void m (Object o) {
 if (one.equals (o)) {}
 else if (two.equals (o)) {}
 else {}
}

现在 equals 返回 false else 子句将被执行，但在抛出异常时不会被执行。

而且 null 并不真正等于“2”，因此返回 false 是非常有意义的。那么最好坚持 null.equals("b") 也返回 false :))

但这个要求确实产生了一个奇怪的、非对称的等于关系。