在 Android Studio 1.2.2 中使用以下代码的默认设置运行“分析/检查代码”时:

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(this);
        String value = sharedPref.getString("somekey", "default");
        if (value.equals("default")) {
            Log.d("MainActivity", "value matches default");
        }
    }
}

它在“可能的错误”下产生以下警告:

Method invocation 'value.equals("default")' at line 16 may produce 'java.lang.NullPointerException'

但是，如果首选项不存在，将返回默认值。即使首选项的值被显式设置为空:

sharedPref.edit().putString("somekey", null).commit();

将返回默认值(大概在幕后这实际上是在删除首选项，但这在这里并不重要)。

上述代码实际产生 NPE 的唯一方法是在首选项不存在时传递一个 null 值作为默认值:

String value = sharedPref.getString("somekey", null);

但是，如果有人那样做了，他之后遗漏空检查的可能性很小。我确实意识到 null 在这里可能不是文字，可能来自其他变量，但同样，获取首选项的用例不太可能。

我确实意识到“这只是一个警告”，我“可以忽略它”，这是我的代码，我可以“为所欲为”和“lint 不是保姆”以及其他所有内容，但是这让我很烦恼(请原谅双关语)，这个明显微不足道的非错误在代码检查期间显示为“可能的错误”。

现在问题:

1. 我假定的无错误代码中是否存在一些我尚未发现的潜在危险？
2. 代码检查是否不够智能？
3. 在代码检查期间实际触发此警告的是什么？
4. 如何消除警告？

为了尝试回答 4。我想出了以下内容:

1. 没什么，只是忽略输出。看起来很丑，而且看起来你根本没有考虑警告。
2. 禁用整类警告。可能会隐藏其他真正的错误。
3. 经典，将周围的等号更改为"default".equals(value)。不适用于 switch(value){...}
4. 只需添加一个单独的空检查 if (value != null) {...}。多余的支票，投降的味道。

试图回答 3。我做了一些实验:

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        String value = null;
        if (value.equals("default")) {
            Log.d("MainActivity", "value matches default");
        }
    }
}

产生预期的警告并按预期爆炸。很公平。

下一步...

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        String value = "test";
        if (value.equals("default")) {
            Log.d("MainActivity", "value matches default");
        }
    }
}

没有警告，没有崩溃。显然。

下一步...

public class MainActivity extends Activity {
    private String getString() {
        String value = null;
        if (new Random().nextBoolean())
            value = "test";
        return value;
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        String value = getString();
        if (value.equals("default")) {
            Log.d("MainActivity", "value matches default");
        }
    }
}

显然随机崩溃(字面意思)，但没有警告!哎哟。

所以，让我们在 getString() 上添加一个 @Nullable 注释。现在我们得到了警告，很好。但是，SharedPreferences getString() 上似乎没有注释。

好吧，让我们试试相反的方法。在 getString() 上粘贴一个 @NonNull。新警告:

Expression 'value' might evaluate to null but is returned by the method declared as @NotNull (at line 28)

很酷，所以代码检查知道 getString() 的结果可能为 null，但为什么它在尝试使用时不给我们原始警告返回值？

更新

这里还有另一个隐含的问题，我第一次可能没有足够强调。

此特定代码检查的描述如下:

Variables, method parameters and return values marked as @Nullable or @NotNull are treated as nullable (or not-null, respectively) and used during the analysis to check nullability contracts, e.g. report possible NullPointerException errors.

这似乎暗示这些注释是导致警告的原因。

事实上，当使用 @Nullable 注释时，我自己的方法仅 生成警告。然而，SharedPreferences getString() 生成此警告，尽管它未 注释。这是为什么？

最佳答案

Is there some lurking danger in my presumed bug-free code that I haven't seen yet?

可能不会。关注分析器结果并努力通过修复或有选择地抑制它们来消除任何问题仍然是有意义的。

Is the code inspection just not smart enough? What actually triggers this warning during code inspection?

是的，它不够聪明。

分析器可以看到一个方法可以返回 null 并且返回值被未经检查地使用，但不能足够深入地推理出您的代码中不会出现这种情况。

What can be done to remove the warning?

喜欢

"default".equals(value)

尽可能采用您已经发现的样式。这使您在所有情况下都可以进行无 NPE 的比较，并且还可以防止分析器出现故障。

如果不可能，在本地抑制警告，例如:

//noinspection ConstantConditions    
switch (value) {
    ...

关于android - 为什么对默认值报告 "may produce NPE"的 SharedPreferences.getString() 进行代码检查？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31404261/