在我的 Android 应用程序中清理一些松散的东西时，我在开发人员控制台中发现了一个空指针异常，这从未发生过，我猜这是一种罕见的竞争条件。
对于那些不知道的人：Android 允许用户向开发人员报告崩溃（即未捕获的异常）。
if (… != null)当我想到这个臭名昭著的东西时，我已经开始打字了：只有三份报告。所以它很少发生。
所以我想知道：在这种情况下，性能方面：捕获空指针异常不是更好吗？
考虑到 if 每次都会被评估。
问问题
191 次
5 回答
8
听起来不像是一个狂热或心胸狭窄的人，但我坚信从一开始就不应该允许 NPE 发生！在我看来，捕捉 NPE 是一种非常糟糕的做法。这意味着您并不完全了解您的代码是如何工作的。
在使用某些输入之前，您应该始终做的第一件事是检查是否为空。
于 2012-05-01T12:29:08.010 回答
3
“每次”的频率是多少？每次加载一次？每一分钟？每秒1000次？
在任何情况下，测试obj == null都是尽可能便宜的操作，而且肯定比异常处理便宜。
并且永远不应该发生空指针异常——它们需要被理解和防止。如果您不知道为什么会发生这种情况，则需要对其进行修复。
于 2012-05-01T12:29:33.983 回答
2
应使用异常来处理异常情况。也就是说，如果预期该值可能为 null，那么检查它而不是捕获异常是合理的。我想不出任何例子，其中捕获 aNullPointerException比在正常控制流中处理它更好。
于 2012-05-01T12:30:13.250 回答
0
我在开发人员控制台中发现了一个空指针异常，这从未发生过，我猜这是一种罕见的竞争条件
这听起来像一个错误，只是捕捉到异常听起来你打算忽略这个错误而不是修复它。找出这些空值的来源并修复它，不要让空指针传播到无法处理它们的代码。
于 2012-05-01T13:07:02.173 回答
0
如果它是多线程竞争条件，是否有可能变量正在初始化然后再次设置为 null？如果是这样，“如果（...！= null）”可以通过，然后仍然会出现异常。
为了安全起见，我会使用 try catch （应该避免未处理的空指针异常），但也会尝试找到竞争条件，如果可能或可在可监督的时间内修复或处理它。
如果异常似乎绕过竞争条件（不是很漂亮但有效），您也可以等待几毫秒并重试一定次数。
于 2012-05-01T12:32:57.023 回答