我正在编写一个库，它具有多个公共类和方法，以及库本身使用的多个私有或内部类和方法。
在公共方法中，我有一个空检查和一个抛出，如下所示：
public int DoSomething(int number)
{
if (number == null)
{
throw new ArgumentNullException(nameof(number));
}
}
但这让我开始思考，我应该在方法中添加参数空检查到什么级别？我是否也开始将它们添加到私有方法中？我应该只对公共方法这样做吗？
最终，对此并没有形成统一的共识。因此，我不会给出是或否的答案，而是尝试列出做出此决定的考虑因素：
空检查会使您的代码变得臃肿。如果您的过程很简洁，则它们开头的空防护可能会构成过程整体大小的重要部分，而不会表达该过程的目的或行为。
空检查明确地规定了一个前提条件。如果某个方法在其中一个值为 null 时会失败，那么在顶部进行 null 检查是向临时读者演示这一点的好方法，而无需他们寻找取消引用的位置。为了改善这一点，人们经常使用名称如下的辅助方法Guard.AgainstNull，而不必每次都写支票。
私有方法中的检查是不可测试的。通过在代码中引入无法完全遍历的分支，就无法完全测试该方法。这与测试记录类的行为以及该类的代码的存在是为了提供该行为的观点相冲突。
让空值通过的严重程度取决于具体情况。通常，如果为空does进入该方法，几行后它将被取消引用，您将得到一个NullReferenceException。这实际上并不比抛出一个更不清楚ArgumentNullException。另一方面，如果该引用在取消引用之前被传递了相当多的时间，或者如果抛出 NRE 会使事情处于混乱状态，那么尽早抛出就更重要了。
一些库（例如 .NET 的 Code Contracts）允许一定程度的静态分析，这可以为您的检查带来额外的好处。
如果您正在与其他人一起开发一个项目，则可能有现有的团队或项目标准涵盖了这一点。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
