java - Java-在不允许使用@NotNull或@Nullable批注时在编译时检测NPE的最佳方法

我曾经使用很多@NotNull/@Nullable批注来启用IDE，以帮助我在编译时找出潜在的NPE。但是，我的新团队不允许使用@NotNull/@Nullable批注，也不允许像这样的自定义批注。结果，与以前相比，我更有可能编写由NPE引起的错误。

我尝试了几种解决方案:

在Java 8中使用Optional<T>。但是，这并非在每种情况下都很好。通常不建议使用Optional<T>作为字段或参数的类型。 Optional<T>实例本身可能是null也非常令人沮丧。另外，调用ifPresent(obj->...)时，很难在lambda表达式中操作控制流(在Java 9中更容易)。使用太多的Optional<T>会使代码有些冗长。 (更新:很遗憾，现在也禁止使用Optional<T>)

使IDE将每个未注释的实例视为@Nullable。该解决方案确实帮助我发现了一些潜在的错误，但是，IDE建议我检查几乎所有方法调用，这确实很烦人，因为许多方法是有意设计的，没有返回null。

检查每个方法调用。这是一个可行的解决方案，但是它对null的可能性将通过方法调用传递到任何地方都具有严重的影响。在这种情况下，方法的每个参数都可以是null，并且当检查参数是否为空时，该方法通常会连续返回null。最后，每个方法都被“感染”，有可能接收null参数并返回null。

调用Objects.requireNonNull()可以防止上述问题。它稍微减轻了在任何地方检查null的麻烦。但是，它不能保证调用者不会将null传递给不允许null的情况。一旦传递了null，则抛出的运行时NPE更有可能破坏您的应用程序。

切换到kotlin。当然，这是不允许的:)

关于在编译时检测NPE(并保存我的工作)还有其他建议吗？ 我认为可以广泛使用此问题的解决方案，不仅可以帮助自己，因为并非所有团队都允许使用@NotNull/@Nullable批注和Optional<T>。

最佳答案

不是确定的答案，而是一些探索的方法:

像findBug，PMD，Coverity ...之类的工具在此练习中相当出色。

检查无法在团队中使用注释的原因。也许您可以使您的团队改变主意？ (也许也有很好的理由。)

在这个练习上，Eclipse IDE表现出色。您是否尝试过“Windows>首选项> Java>编译器>错误/警告>空分析”中的选项？

单元测试。在一些测试案例中介绍“不应该发生”的情况。最好使用代码覆盖率工具(例如JaCoCo)。

防御性编程(普通的“if”语句，断言……)

以前的项目的组合

希望这可以帮助。