在Java中,如果空指针很少发生,最好使用catch而不是if

时间:2012-05-01 12:26:21

标签: java android exception-handling nullpointerexception

在我的Android应用程序中清理一些松散的东西我在开发者控制台中发现了一个空指针异常,这种情况从来没有发生过,我认为这是一种罕见的竞争条件。

对于那些不知道的人:Android允许用户向开发人员报告崩溃(i.E.未捕获的异常)。

我已经开始输入臭名昭着的if (… != null),当它发生在我身上时:只有三个报告。所以它很少发生。

所以我想知道:在这种情况下,性能明智:更好地捕获空指针异常会不会更好?

考虑每次都会评估if。

5 个答案:

答案 0 :(得分:8)

不要听起来像一个狂热或心胸狭窄的人,但我坚信 NPE绝不应该被允许首先出现!在我看来,捕捉NPE是一种非常糟糕的做法。这意味着您并不完全了解代码的工作方式。

在使用某些输入之前,您应该始终做的第一件事是检查null。

答案 1 :(得分:3)

“每次”多久一次?每次加载一次?每一分钟?每秒1000次?

无论如何,obj == null的测试与您可以获得的操作一样便宜,而且肯定比异常处理便宜。

永远不应该发生空指针异常 - 需要理解并阻止它们。如果你不知道为什么会这样,那就需要修复。

答案 2 :(得分:2)

应该使用例外来处理特殊情况。也就是说,如果预期值可能为null,则检查它而不是捕获异常是合理的。 我想不出任何一个例子,其中捕获NullPointerException比在正常控制流中处理它更好。

答案 3 :(得分:0)

如果它的多线程竞争条件可能正在初始化变量然后再次设置为null?如果是这样," if(...!= null)"可以通过,然后仍然会出现异常。

我使用try catch是安全的(未处理的空指针异常是应该避免的事情)但是也试图找到竞争条件,如果可能或可管理的,在可监督的时间内修复或处理。

如果异常似乎绕过竞争条件(不是很漂亮但有效),您也可以等待几毫秒并重试一段时间。

答案 4 :(得分:0)

  

我在开发者控制台中找到了一个空指针异常从未发生过,我的猜测这是一种罕见的竞争条件

这听起来像一个错误,只是捕捉异常声音,就像你打算忽略错误而不是修复它。找出这些空值的来源并修复它,不要让空指针传播到无法处理它们的代码。