C# 处理或不处理带异常的空参数

我记得读过一些异常处理指南，不鼓励检查空参数。这样做的理由是，如果代码保持原样，则在尝试使用该参数时会引发异常（NullReferenceExcpetion）。另一种方法是显式检查null并引发ArgumentNullException

这会产生同样的效果，但你是对的，额外的代码行。您永远不会编写代码来处理这两种异常，因此在运行时测试时确实会遇到这些异常，然后修复代码以首先阻止异常的发生

我并不是说我同意指南，但当我第一次阅读它时，它确实有意义，现在仍然有意义

我通常只检查非私有方法上的null参数，但将私有方法留给引发NullReferenceException

是否有人知道在这方面是否有明确的/事实上的最佳指导实践，以便我可以在需要时更新我的方法

这会产生同样的效果，但你是对的，额外的代码行

不，没有。考虑：

public void TransferMoney(Account from, Account to, decimal amount)
{
    from.Debit(amount);
    to.Credit(amount);
}

vs

两种方法都会失败，但第一种方法会失败，因为它首先会产生副作用。这很糟糕，应该尽可能避免

（显然，在真实场景中，这可能是事务性的，不会造成任何实际伤害，但你可以接受我的观点。）

此外，如果一个参数用作另一个方法的参数，或者更糟糕的是，存储起来供以后使用，那么最终可能会从一个完全不同的地方抛出异常，这种方式可能会使原始问题变得完全不明显

我通常只检查非私有方法上的null参数，但将私有方法留给引发NullReferenceException

---

这似乎是一项相当合理的政策。如果从一些毛茸茸的代码中调用私有/内部方法，并且我担心可能会把事情弄糟，我有时甚至会验证它。

通过检查，您可以在异常中传递参数名，这简化了调试

if (x == null) throw new ArgumentNullException(nameof(x));

---

不确定，但对我来说区别在于参数[Null]异常表示输入已被验证并被故意拒绝，而NullReferenceException表示未经检查地使用未分配的引用（甚至可能在原始调用时都没有），这可能是一个bug。我倾向于在公共方法中使用ArgumentNullException，在私有方法中使用Debug.Assert。通过使用代码片段插入空检查和抛出，可以稍微减轻额外代码行的繁琐工作。

if (x == null) throw new ArgumentNullException(nameof(x));