为什么要显式抛出NullPointerException而不是让它自然发生？

阅读JDK源代码时，笔者通常会检查参数是否为null，然后手动抛出新的NullPointerException（）。他们为什么这样做？我认为没有必要这样做，因为它在调用任何方法时都会抛出新的NullPointerException（）。（例如，以下是HashMap的一些源代码：）

public V computeIfPresent(K key,
                          BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    if (remappingFunction == null)
        throw new NullPointerException();
    Node<K,V> e; V oldValue;
    int hash = hash(key);
    if ((e = getNode(hash, key)) != null &&
        (oldValue = e.value) != null) {
        V v = remappingFunction.apply(key, oldValue);
        if (v != null) {
            e.value = v;
            afterNodeAccess(e);
            return v;
        }
        else
            removeNode(hash, key, null, false, true);
    }
    return null;
}

我想到许多原因，其中一些原因密切相关：

快速失败：如果要失败，最好早点而不是晚点。这样可以使问题更接近问题的根源，从而更易于识别和恢复。它还避免浪费CPU周期，而这些周期注定会失败。

目的：抛出异常可以使维护人员清楚地知道该错误是有目的的，并且作者意识到了后果。

一致性：如果允许错误自然发生，则可能不会在每种情况下都发生。例如，如果找不到映射，remappingFunction则将永远不会使用该映射，也不会引发异常。预先验证输入可提供更多确定性的行为和更清晰的文档。

稳定性：代码会随着时间的推移而发展。自然地，遇到异常的代码可能会在经过一些重构之后停止这样做，或者在不同的情况下这样做。明确地扔掉它可以使行为无意更改的可能性降低。

这是为了清楚，一致，并防止执行额外的不必要的工作。

考虑如果方法顶部没有保护子句，将会发生什么情况。它总是会调用hash(key)，getNode(hash, key)甚至在NPE抛出之前null已传递给它时remappingFunction也是如此。

更糟糕的是，如果if条件是条件，false那么我们采用else完全不使用的分支remappingFunction，这意味着当出现以下情况时，该方法并不总是抛出NPEnull转到传递。是否确实取决于地图的状态。

两种情况都是不好的。如果null不是的有效值remappingFunction该方法应始终引发异常，而不管调用时对象的内部状态如何，并且应该这样做，而不必执行不必要的工作，因为它将要抛出该异常。最后，干净，清晰的代码的一个很好的原则是使保护措施处于正确的位置，以便任何审阅源代码的人都可以很容易地看出来。

即使当前每个代码分支都抛出异常，将来的代码修订版也可能会对此进行更改。从一开始就执行检查，可以确保一定会进行检查。

除了@shmosel的出色答案列出的原因...

性能：（在某些JVM上）（明确地）抛出NPE（而不是让JVM执行）可能（已经）具有性能优势。

这取决于Java解释器和JIT编译器采取的检测空指针取消引用的策略。一种策略是不测试是否为空，而是捕获当指令尝试访问地址0时发生的SIGSEGV。在引用始终有效的情况下，这是最快的方法，但在NPE情况下，这是昂贵的。

null在NPE频繁出现的情况下，对代码中的进行显式测试将避免SIGSEGV性能受到影响。

（我怀疑这在现代JVM中是否值得进行微优化，但它可能已经过去了。）

兼容性：异常中没有消息的可能原因是与JVM本身抛出的NPE兼容。在兼容的Java实现中，JVM抛出的NPE有一条null消息。（Android Java不同。）

除了其他人指出的内容外，值得注意的是约定在这里的作用。例如，在C＃中，您还具有在此类情况下显式引发异常的相同约定，但是它专门是一个ArgumentNullException，它更加具体。（C＃约定NullReferenceException 始终代表某种错误-很简单，它永远不会在生产代码中发生；当然，ArgumentNullException通常也是如此，但是它可能更多是“您不愿意”的错误。了解如何正确使用该库”。

因此，基本上，在C＃中NullReferenceException意味着您的程序实际上尝试使用它，而ArgumentNullException这意味着它认识到该值是错误的，甚至没有费心尝试使用它。实际上，含义可能有所不同（取决于情况），因为这ArgumentNullException意味着所讨论的方法还没有副作用（因为它没有满足方法的先决条件）。

顺便说一句，如果您提出类似ArgumentNullException或的问题IllegalArgumentException，那是进行检查的一部分：您想要的异常不同于“正常”得到的异常。

无论哪种方式，显式地引发异常都可以加强一种良好的做法，即明确说明方法的前提条件和期望的参数，从而使代码更易于阅读，使用和维护。如果您未明确检查null，我不知道是否是因为您认为没有人会传递一个null参数，而是在计算它是否会引发异常，或者只是忘记检查该参数。

这样一来，您将在执行错误后立即获得异常，而不是稍后在使用地图且不了解发生原因时。

它将看似不稳定的错误情况转变为明显的违反合同的情况：该函数具有正常工作的一些先决条件，因此它会预先检查它们，以使其得到满足。

结果是，computeIfPresent()当您摆脱异常时，您不必调试。一旦看到异常来自先决条件检查，便知道您使用非法参数调用了该函数。如果检查不存在，则需要排除computeIfPresent()自身内部存在某些导致引发异常的错误的可能性。

显然，抛出泛型NullPointerException确实是一个糟糕的选择，因为它本身并不表示违反合同。IllegalArgumentException会是一个更好的选择。

旁注：
我不知道Java是否允许这样做（我对此表示怀疑），但是C / C ++程序员assert()在这种情况下会使用，这对于调试而言要好得多：它告诉程序立即崩溃，并在崩溃时尽可能地崩溃。条件评估为假。所以，如果你跑了

void MyClass_foo(MyClass* me, int (*someFunction)(int)) {
    assert(me);
    assert(someFunction);

    ...
}

在调试器中，并将任何东西传递NULL给任一自变量，程序将立即在告诉该自变量为的行处停止NULL，您将可以随意检查整个调用堆栈的所有局部变量。

这是因为它是可能它不是自然发生的。让我们看一下这样的代码：

bool isUserAMoron(User user) {
    Connection c = UnstableDatabase.getConnection();
    if (user.name == "Moron") { 
      // In this case we don't need to connect to DB
      return true;
    } else {
      return c.makeMoronishCheck(user.id);
    }
}

（当然，此示例中有很多关于代码质量的问题。很抱歉懒得想象完美的示例）

情况时，c将不被实际使用，并NullPointerException即使不被拆毁c == null是可能的。

在更复杂的情况下，查找此类情况变得非常不容易。这就是为什么一般检查if (c == null) throw new NullPointerException()更好。

有意保护进一步的损坏或进入不一致状态。

除了这里所有其他出色的答案之外，我还想补充一些案例。

如果您创建自己的异常，则可以添加一条消息

如果您自己丢东西NullPointerException，则可以添加一条消息（绝对应该！）

默认消息是nullfrom new NullPointerException()和使用它的所有方法，例如Objects.requireNonNull。如果您打印该null，它甚至可以转换为空字符串。

有点短而且没有信息...

堆栈跟踪将提供很多信息，但是要使用户知道什么为空，他们必须挖掘代码并查看确切的行。

现在想象一下，NPE是通过网络包装和发送的，例如作为Web服务错误中的一条消息，可能在不同部门甚至组织之间。最坏的情况是，没人会知道null代表什么。

链接方法调用将使您不断猜测

异常只会告诉您异常发生在哪一行。考虑以下行：

repository.getService(someObject.someMethod());

如果你得到一个NPE和它指向该行，哪一个repository和someObject为空？

相反，在获取这些变量时检查它们至少会指向一行，希望它们是唯一要处理的变量。并且，如前所述，如果您的错误消息包含变量名称或类似名称，则更好。

处理大量输入时的错误应提供识别信息

想象一下，您的程序正在处理具有数千行的输入文件，并且突然出现NullPointerException。您看了一下地方，发现有些输入不正确...什么输入？您将需要有关行号的更多信息，也许是列甚至整个行的文本，以了解该文件中的哪行需要修复。