我应该在私有/内部方法中抛出空参数吗? [英] Should I throw on null parameters in private/internal methods?

问题描述

我正在编写一个具有几个公共类和方法的库，以及该库本身使用的几个私有或内部类和方法.

I'm writing a library that has several public classes and methods, as well as several private or internal classes and methods that the library itself uses.

在公共方法中，我有一个空检查和一个这样的抛出:

In the public methods I have a null check and a throw like this:

public int DoSomething(int number)
{
    if (number == null)
    {
        throw new ArgumentNullException(nameof(number));
    }
}

但是这让我开始思考，应该将参数空值检查添加到什么级别?我是否也开始将它们添加到私有方法中?我应该只为公共方法这样做吗?

But then this got me thinking, to what level should I be adding parameter null checks to methods? Do I also start adding them to private methods? Should I only do it for public methods?

推荐答案

最终，对此没有统一的共识.因此，除了给出是或否的答案外，我将尝试列出做出此决定的注意事项:

Ultimately, there isn't a uniform consensus on this. So instead of giving a yes or no answer, I'll try to list the considerations for making this decision:

• Null检查膨胀代码.如果您的程序简洁明了，则在它们开头的空防护符可能会构成该程序总体大小的重要组成部分，而不会表达该程序的目的或行为.

• Null checks bloat your code. If your procedures are concise, the null guards at the beginning of them may form a significant part of the overall size of the procedure, without expressing the purpose or behaviour of that procedure.

空检查明确表示前提条件.如果一个方法在其中一个值为null时将失败，则在顶部进行null检查是向不经意的读者展示此方法的好方法，而无需他们寻找被取消引用的位置.为了改善这一点，人们通常使用名称为Guard.AgainstNull的辅助方法，而不必每次都写支票.

Null checks expressively state a precondition. If a method is going to fail when one of the values is null, having a null check at the top is a good way to demonstrate this to a casual reader without them having to hunt for where it's dereferenced. To improve this, people often use helper methods with names like Guard.AgainstNull, instead of having to write the check each time.

私有方法中的检查是不可测试的.通过在代码中引入一个分支，而您无法完全遍历该分支，那么就不可能完全测试该方法.这与测试记录了类的行为以及存在该类的代码以提供该行为的观点相冲突.

Checks in private methods are untestable. By introducing a branch in your code which you have no way of fully traversing, you make it impossible to fully test that method. This conflicts with the point of view that tests document the behaviour of a class, and that that class's code exists to provide that behaviour.

允许空值通过的严重性取决于情况.通常，如果将空确实插入该方法，则稍后将取消引用该行，您将得到一个NullReferenceException.这确实比抛出ArgumentNullException清晰得多.另一方面，如果该引用在被取消引用之前经过了很多传递，或者如果抛出NRE会使事情陷入混乱状态，则尽早抛出更为重要.

The severity of letting a null through depends on the situation. Often, if a null does get into the method, it'll be dereferenced a few lines later and you'll get a NullReferenceException. This really isn't much less clear than throwing an ArgumentNullException. On the other hand, if that reference is passed around quite a bit before being dereferenced, or if throwing an NRE will leave things in a messy state, then throwing early is much more important.

某些库(如.NET的代码合同)允许一定程度的静态分析，这可以为您的检查增加额外的好处.

Some libraries, like .NET's Code Contracts, allow a degree of static analysis, which can add an extra benefit to your checks.

如果您正在与其他人一起开发项目，则可能存在现有的团队或项目标准.

If you're working on a project with others, there may be existing team or project standards covering this.

这篇关于我应该在私有/内部方法中抛出空参数吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！