有效的Java建议我们不要捕获NullPointerException。总是对的吗？
在几乎所有情况下，它都是正确的。
NullPointerException通常是错误的结果；也就是说，您的应用程序
null在无法预期的情况下遇到了对象引用，然后尝试使用它。在这种情况下，由于您（程序员）没有预料到
null，因此几乎不可能知道
尝试
恢复是否安全和/或知道可能需要进行什么“补救”。因此，最好的办法是让NPE传播到基本级别，然后将其视为通用错误。（在“网络服务”应用程序中，返回“服务错误”响应并尝试继续是合适的。）
另一种情况是您（程序员）期望
null交付a。在这种情况下，最好的策略是（几乎总是）
null在 尝试使用它 之前 进行显式测试，从而
避免 了NPE …以及处理它的需要。有两个原因：
异常处理通常很昂贵。的确，这可能比测试一个版本昂贵 许多数量级
null
。如果您允许预期的NPE发生然后捕获它，您也有可能捕获其他 意外的 NPE …并错误地处理它们。
请注意，我通过说“几乎总是”来限定以上条件。从理论上讲，有可能发生显式测试使
null代码混乱的情况，至少值得 考虑
让NPE发生。但是，仍然存在意外的NPE的可能性，具体取决于代码。因此，这种方法始终是 潜在的 脆弱。
（FWIW-我从来没有遇到过这样的好主意的真实案例……）
在捕获NullPointerException的许多情况下，catch主体仅调用printStackTrace（）。
那可能是错误的代码。无所事事很少是从NPE恢复的正确方法。
如果我没有捕获NullPointerException并调用printStackTrace（），如何检查异常发生的地方？
您让NPE传播到基本级别。在那里，您捕获并打印（或记录） 所有 未处理的异常的堆栈跟踪，然后纾困或尝试恢复……如果可行的话。
而且，如果我捕获了NullPointerException并且catch主体为空，那么我们当时无法获取任何堆栈信息，可以吗？
永远不要这样做！它被称为“挤压”，很 危险 。（特别是因为如上所述，NPE可能是由于您/您的代码未曾预料到的。）
不，如果执行此操作，则无法获取堆栈跟踪。没了
跟进
我对“规避NPE” 1的一些一般策略没有太多信任/信念。例如这样的东西：
return (someObject != null) ? someObject.toString() : "";
总是让我怀疑程序员 没有考虑这个问题 。为什么首先是
someObjecta
null？
NPE是由
null您不期望的地方引起的。因此，NPE通常是问题的 征兆
，而不是实际问题本身。在我看来，NPE不可避免。相反，您应该使用NPE来查找和修复意外事件的
根本原因
null。像上面这样的代码可以避免NPE阻碍该目标的实现。
因此，我更喜欢/推荐一些避免
null在意料之外的地方采取措施的策略。
确保将每个引用字段初始化为非空值…除非
null
是 有意义的 值。尽量避免具有
null
有意义的值，尤其是在有其他选择的情况下。例如，一个空的String，一个零长度的数组，一个空的集合，一个表示“未定义”的专有实例或其他。或者，对于Java 8及更高版本，请使用Optional
。不要
null
作为错误或特殊情况的指示返回。（引发异常或返回可分辨的值。）尽早检查意外
null
值（例如，null
参数），并 尽早（而不是稍后 ）抛出NPE 。在少数几个
null
参数或结果合法的地方，请确保您的javadocs清楚明确地记录了这一点。如果没有文档，则意味着null
不允许这样做，也不会返回。
无论您在哪里获得NPE，都应确保找到并解决问题的 真正 根源……而不仅仅是引发异常的特定声明。
1-了解标准Java
API中
null用作（或滥用）返回值的位置很有用。例如
Class.getResourceAsStream(...)或
HttpRequest.getParam(...)。这些“避免NPE的建议”文档在指出这些陷阱方面非常有用。
