当将Optional.isPresent和Optional.get称为“不同”级别时,显示警告?

Rom*_*hin 1 java intellij-idea optional java-8

在以下代码段中,我的Foo类带有始终返回的相同实例的方法Optional。然后我有另一个OneMoreClass使用Foo类的类。

您可以从源代码中看到调用get()方法是安全的,method1因为始终在中检查该方法method2

IntelliJ IDEA仍然显示警告的问题(您只需将此代码段复制到IDEA,您将看到此问题)。

public class Example {

    public static class Foo {

        private final Optional<String> value = Optional.empty();

        public Optional<String> bar() {
            return value;
        }
    }

    public static class OneMoreClass {
        void method1(final Foo foo) {
            method2(foo);
            System.out.println(foo.bar().get()); // here the warning is shown in IntelliJ IDEA: 
                                                 // "Optional.get()" without "isPresent()" check
        }

        void method2(final Foo foo) {
            if (!foo.bar().isPresent()) {
                throw new IllegalArgumentException("No value");
            }
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

问题是:如何解决警告?有什么技巧可以避免此警告?

Tag*_*eev 5

披露:我是IntelliJ IDEA开发人员,负责此功能。


从技术上讲,get()使用以下代码可能会导致失败:

public static void main(String[] args) {
    new Example.OneMoreClass().method1(new Example.Foo() {
        int x;

        @Override
        public Optional<String> bar() {
            return x++ % 2 == 0 ? Optional.of("foo") : Optional.empty();
        }
    });
}
Run Code Online (Sandbox Code Playgroud)

由于您的Foo类和bar()方法不是最终的,因此IDEA无法确保它们是稳定的。但是,即使您声明Foo为final ,IDEA仍会发出警告。我们实际上相信该bar()结果可能是稳定的,以避免发出噪声警告。主要问题是将isPresent()支票转移到单独的方法中,而我们的过程间分析不是那么聪明。当调用未知的用户方法时,当前的分析器实现仅做几件事情:

  1. 我们可以推断结果为可为零,结果可变性(在非常有限的意义上),方法的纯度和契约,就像@Contract("null -> false")研究方法的实现一样。此分析非常有限,仅适用于不可覆盖的方法,因此不适用于此方法。即使我们声明method2为final,该分析也不会产生任何结果。

  2. 我们推断非空参数,并研究方法的实现。这适用于您的情况:如果您致电method2(null),则会收到警告。当然,解决您的问题没有帮助。

  3. 在某些情况下,我们内联非常小的简单稳定方法。仅当要内联的方法是稳定的,没有参数,在同一类上调用,具有单个return语句且不调用任何其他方法(可能有更多限制)时,此方法才有效。它在以下情况下有帮助:

    public static final class OneMoreClass {
        @Nullable String foo;

        void test() {
            if (isValid()) {
                System.out.println(foo.trim()); // no possible NPE warning
            }
        }

        boolean isValid() {
            return foo != null;
        }
    }
Run Code Online (Sandbox Code Playgroud)

这些方法都不能解决您的情况。我们有时会改进分析以使其更智能,但是我们在CPU资源方面非常有限。别忘了我们在线分析代码,并且不断对代码进行编辑,从而使先前的分析结果无效。深入的过程间分析需要更多的CPU时间,我们不希望IDEA显着降低。

我必须说您的代码也可能使读者感到困惑。我认为您的示例是较大代码的简化版本,读者可能不确定在给定的代码点实际上是否始终存在可选选项。有一个很好的旧机制可以帮助代码读取器并保护自己免受意外错误的影响(如果有人修改了method2之后又在isPresent()没有适当调整调用站点的情况下删除了支票,该怎么办?)。该机制称为断言。因此,答案是:添加一个断言,对于IDE和读者而言,代码将更加清晰:

    void method1(final Foo foo) {
        method2(foo);
        assert foo.bar().isPresent();
        System.out.println(foo.bar().get()); // the warning is gone
    }
Run Code Online (Sandbox Code Playgroud)