是否可以对潜在的空对象引用进行静态代码验证？答案

【问题标题】：Is static code verification for potential null object references available?是否可以对潜在的空对象引用进行静态代码验证？
【发布时间】：2012-04-11 15:44:23
【问题描述】：

我想要一种在对象引用可能引发空引用异常时获得警告的方法，以便我可以为这些编写防御性代码。

我查看了 Resharper，但没有看到任何可以实现这一点的东西。

Code Contracts 可能无法启动；该应用程序非常大，它是在代码合同正式可用之前用 .NET 3.5 编写的。

【问题讨论】：

总是检查对象的引用是否是null不是更容易吗？你也可以走另一条路，确保你使用的对象不能为空。
对于每个对象引用？ :o 其中一些永远不会为空（它们在构造函数中设置）。
即使你没有使用代码契约，你也应该在方法的开头写上保护子句。
代码合同与 .NET 3.5 有什么关系？

标签： c# .net-3.5 static-analysis

【解决方案1】：

Resharper 实际上确实完成了类似的事情。可能的 NullReferenceExpections 在 IDE 中以蓝色突出显示，当您将鼠标悬停在它们上方时会显示工具提示。

Resharper 然后在它自己的检查结果窗口中跟踪潜在的错误和警告（与 Visual Studio 的编译器错误和警告分开）。

【讨论】：

它们会出现在分析警告列表中吗？他们可能正被其他警告淹没。
哦，我明白你的意思了。它们不会出现在 VS 错误列表中； Resharper 维护自己的窗口，用于导航和跟踪代码问题。相应地更新我的答案。
@RobertHarvey 你最终使用了 ReSharper 吗？我刚刚尝试过试用，看看它是否发现了类似的空问题（确实如此），但默认情况下它给了我几千个解决方案的警告/错误，其中很多我没有关心。
@Stijn：是的，我试过了，是的，它确实给出了很多我不关心的警告，但你可以过滤和更改显示设置，只看到你想要的错误见。

【解决方案2】：

一般来说，除非你专门初始化了一个对象，否则它总是有可能抛出一个空对象引用，至少就编译器而言。

为了让算法检查对对象的引用是否可能为空，它必须遍历您的程序可以采用的所有可能路径，其中包括您可能正在使用的任何外部库中的路径。即使是最简单的程序，这样的算法也会降低编译器的性能。

【讨论】：

好吧，我编译时不一定要检查每次。大多数情况下，我正在寻找“第一次机会”异常，而不是初始化对象但可能稍后设置为 null 的情况（如果有的话，我很少这样做）。

【解决方案3】：

我反对为代码和每个方法中的每个可用字段盲目地防御 null 的想法。

以下内容帮助我决定在哪里检查空值：

1- 谁将调用您的方法？
如果一个方法是私有的并且您可以控制它是如何被访问的，那么我认为防止空检查是没有意义的，除非它是方法逻辑的一部分来期望空值。如果某个方法公开（例如 API），那么 null 检查当然应该是一个大问题。

2- 软件设计：
您正在调用 method1(fromAnimalToString(animal)); 的图像，由于某种原因，fromAnimalToString() 从不返回 null （尽管可能会返回一个空字符串）。
那么在这种情况下，在 method1() 的主体中检查 animal != null 是没有意义的

3- 测试：
在软件工程中，几乎不可能测试所有可能执行的场景。但是，请测试正常和替代方案并确保流程符合预期。

【讨论】：

我问这个问题是因为我已经发布了几次项目进行测试，并且出现了在我的开发测试中不明显的空引用异常。
我认为在理想的环境中，开发人员会尽力减少错误的发生。在复杂系统的情况下，QA 的工作是尝试生成开发人员没有想到的场景，以便在 QA 阶段可以找到可能导致 NullPointerExceptions 的替代场景。在这种情况下，仅检查 null 可能还不够，还要根据导致参数为 null 的原因采取适当的逻辑措施。