始终检查参数并抛出异常

当参数不符合您的预期时,您是否应始终检查参数并在.NET中引发异常？例如null对象或空字符串？

我开始这样做了,但后来认为如果在每一种方法上完成,这会使我的代码膨胀很多.我应该检查私有和公共方法的参数吗？

我最终抛出了很多ArgumentNullException("name")异常,即使处理异常的代码不能以编程方式执行任何不同的操作,因为不能保证"name"将来不会更改.

我认为这个信息在查看充满异常信息的日志时非常有用吗？

最好的做法是始终"平易近人".

我的两分钱:所有公共方法应该始终检查传入的参数的有效性.这通常称为"按合同编程",这是一种快速捕获错误并避免通过私人函数传播它们的好方法,许多人会争辩说(包括我自己)不应该直接进行单元测试.抛出异常,如果你的函数或程序无法纠正错误本身,它应该抛出异常,因为它已被抛入无效状态.

对于公共方法,那么是:检查你的论点肯定是必要的; 对于内部/私人电话,Eric Lippert可能会将其归类为"笨蛋"(此处); 他的建议是不要抓住他们......修复代码!

为避免代码膨胀,您可能需要考虑AOP,例如postsharp.为了说明,Jon Skeet有一个postharp属性,可以在这里进行空参数检查.然后(引用他的例子),你可以简单地归因于方法:

[NullArgumentAspect("text")]
public static IEnumerable GetAspectEnhancedEnumerable(string text)
{ /* text is automatically checked for null, and an ArgumentNullException thrown */ }

另一个方便的技巧可能是扩展方法; 扩展方法有一个奇怪的功能,你可以在空实例上调用它们...所以你可以做以下(使用泛型而不是"对象"是这样你不会意外地通过装箱值类型调用它) :

static void ThrowIfNull(this T value, string name) where T : class
{
    if (value == null) throw new ArgumentNullException(name);
}
// ...
stream.ThrowIfNull("stream");

并且您可以使用超出范围等来执行类似的操作.

没有比追逐未设置为对象实例的对象引用更糟糕的了.如果你的代码是非常复杂,很难知道什么是失败的-尤其是在生产系统中,尤其是如果它在一个罕见的边界条件.显式异常在解决这些问题方面有很长的路要走.这是一个痛苦,但它是如果东西不好,你不会后悔的一件事情不会发生.