如何获得有关由返回 null 的函数引起的 NPE 的警告？

Question

背景

有时，函数在某些情况下返回 null，但使用它们的人并没有意识到这一点，因此 NPE 是不可避免的。

例如（它只是一个示例，以说明我在说什么）：

public class Test
  {
  public static void main(final String[] args)
    {
    final int t=0;
    System.out.println("result:"+foo(t).toString()); // no warning here...
    }

  public static String foo(final int t)
    {
    if(t>0)
      return "positive";
    else return null;
    }
  }

问题

Eclipse 不会警告这样的事情，甚至在设置中也没有。

只有在不涉及任何功能时才能检测到此类问题（请参阅下面的我的编辑）。

不仅如此，我还找不到说明返回值可以为空的注释。我认为它有相反的效果。

我尝试过的

所以我认为由于 Eclipse 没有一些检查（这很好），我可以使用替代的静态代码分析工具，例如 FindBugs 和 CodePro Analytix 。两者都未能找到此类错误。

我已尝试联系这两个项目，但尚未得到任何答复。对于 CodePro，我什至不确定我是否做对了……事实上，我认为这个项目已经停止（最后一次更新是 2010 年……）。

问题

是否有任何工具可以帮助避免此类错误？

---

编辑：由于许多人认为这可以通过更改代码来解决，因此请考虑在一个庞大的团队中工作，而有些人可能已经忘记了它（每个人都可能犯错误）。或者，您甚至可能正在开发一个使用 SDK（甚至可能是封闭源代码）的项目，该 SDK 在某些情况下可能返回 null，但由于 SDK 的创建者忘记了它，因此没有记录在案。

无论你是一名多么优秀的程序员，这种事情都可能发生。

我要求的是通过让 eclipse 帮助来克服这个问题的方法。它应该能够警告我，至少在我在这里写的基本示例上。

Eclipse 应该能够进行这样的检查，就像它可以警告我这个例子一样：

int t=0;
--t;
String s="s";
if(t<0)
  s=null;
System.out.println(s.toString()); // here you will get a warning

当你在 Eclipse 的设置中启用它时可以检测到：

Java-> Compiler-> Errors/Warning-> Potential null pointer access

我喜欢 Eclipse，因为它有很多很酷的警告和错误，可以帮助避免错误，但我上面写的内容无法被它检测到，甚至无法被我谈到的工具检测到。

许多错误很难找到，没有人是不犯错误的完美程序员。即使您确实知道很多，您也不会受到其他人的错误的保护。人们甚至可能无法找到基本代码的问题（请参阅here、here 或只是here，看看你自己能找到多少错误）。这就是为什么有一些工具可以帮助您。

Answer 1

考虑在您的代码中使用@Nullable 和@NonNull 注释。它可以部分解决您的问题。

更新：从http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_annotations.htm复制的使用示例

@NonNull String getString(String maybeString) {
    if (maybeString != null)
        return maybeString;                         // the above null check is required
    else
        return "<n/a>";
}
void caller(String s) {
    System.out.println(getString(s).toUpperCase()); // no null check required
}

更新：@Nullable 的情况

public @Nullable String getMessage() {
    return System.currentTimeMillis() % 2 != 0
        ? "That's odd..."
        : null;
}

public void showCase() {
    String msg = getMessage();
    if (msg.isEmpty()) { //- Here it yields about possible null access
        //...
    }
}

更新：我的环境中的空分析设置：

来自 Eclipse 的实际错误消息：

更新：您需要在构建路径中包含带有 Eclipse 注释的 JAR。将鼠标指针移动到无法编译的@NonNull 或@Nullable 注释上（如图所示），然后选择使用默认空注释复制库来构建路径 —

新的 JAR 应该出现在 Package Explorer 中并且编译器应该能够看到它。然后将光标移动到注释并按 Ctrl+Space — Eclipse 应该找到正确的导入（注意，您可能会在列表中看到两个不同的包 — 从 JDT 中选择一个） — 并选择它。它应该可以工作。

Answer 2

为您的代码编写单元测试：

@Test
public void testFooWithZero() {
    try{
        Test tester = new Test();
        assertEquals("Expect string returned", "positive", tester.foo(0));
    catch(NullPointerException npe) {
        fail("Threw NPE");
    }
}

它们不仅描述了您的预期行为（通常比懒惰编写的 Javadoc 更好），还保证您的代码符合您的预期。

为正面和负面场景编写测试，你就很成功了。

静态代码分析当然有它的好处，但也有它的局限性——常见的情况是如何防止 get(Object) 从 HashMap 或类似集合返回 null。 SCA 无法在运行时知道集合中有哪些数据。您也无法对核心 Java 包或第三方的代码进行注释。

单元测试应该以互补的方式使用，并且会提高代码的质量。请参阅此问题，了解您应该考虑它的几个好处和原因：

Is Unit Testing worth the effort?

Answer 3

方法有两种方式来表示这种“失败”。返回 null 或抛出异常，这通常在 javadoc 中指示。返回 null 本身并不是错误，因为例如 HashMap.get(key) 将返回 null，如果没有与键关联的值。让HashMap 抛出异常将是一个糟糕的选择。另一方面，如果没有找到实体（例如，请求一个预期存在的唯一实体），一些 JPA 方法会抛出异常。

想象一下，如果您每次使用 HashMap，eclipse 都会说“小心，它可能会返回 null”，您会收到多少警告。

所以总结一下：在现实生活中警告它不会很有用，因为你会因为混乱而开始忽略警告。