几个月前，我问过一个关于C和C ++的类似问题，但最近由于整个“Windows Phone”事情，我更加关注C＃。
那么，在C＃中，方法边界应该检查NULL吗？我认为这与C和C ++不同，因为在C＃中，人们通常可以确定给定引用是否有效--编译器将防止将未初始化的引用传递到任何地方，因此唯一剩下的可能错误是它为空。此外，在.NET Framework内部定义了一个特定的异常ArgumentNullException，它似乎对程序员认为应该在传递无效null时获得的内容进行了编码。
我的个人观点再次是，调用者这样做是有问题的，而且说到底，应该向他们抛出NREs直到永远。然而，我对此比在本机代码领域要少得多--C＃在某些方面与C或C ++相比具有非常不同的编程风格。
那么...在C＃方法中应该检查空参数吗？
是的，检查它们。最好使用代码合同告诉调用者您需要非空参数。
void Foo(Bar bar) {
Contract.Requires(bar != null);
}
这特别有利，因为客户端可以清楚地看到参数所需的内容。
如果不能使用代码契约，请使用守卫条件。
void Foo(Bar bar) {
Guard.Against<ArgumentNullException>(bar == null);
}
快速失败。
Contract.Requires(bar != null); 会标记 Foo(null); 吗？我对此表示怀疑，那么相较于使用 if 进行简单的空值检查，使用这种方式的优势是什么呢？ - Bala RSystem.Diagnostics.Contracts 命名空间中。Guard 是一个常见的实用类，人们有自己的版本，但基本上它只是在满足条件时抛出类型参数中指定的异常。 - jason如果你的方法不希望某个参数为null，我认为最好抛出一个ArgumentNullException（或者像Jason建议的那样使用合同机制）。这是通过合同向客户端传达的更好指示，让客户端在调用你的方法时首先不要传递null。
然后，空值检查成为客户端的责任，这使得双方的代码更易维护（通常是双赢的局面）...至少这是我的感觉。
在公共方法中至少验证所有参数是一个好的实践。这有助于更快地定位错误并且在阅读代码时也很有帮助，因为它描述了方法的契约。
我们实现了一个静态类AssertUtilities，其中包含一堆用于参数和状态验证的方法。我相信有些人将这样的类称为Guard。
例如：
public static void ArgumentNotNull(object argument, string argumentName)
{
if (argument == null)
throw new ArgumentNullException(argumentName);
}
public static void ArgumentInRange(decimal argument, decimal minValue, decimal maxValue, string argumentName)
{
if (argument < minValue || argument > maxValue)
{
throw new ArgumentOutOfRangeException(
argumentName,
FormatUtilities.Format("Argument out of range: {0}. Must be between {1} and {2}.", argument, minValue, maxValue));
}
}
public static void ArgumentState(bool expression, string argumentName, string formatText, params object[] args)
{
if (!expression)
throw new ArgumentException(FormatUtilities.Format(formatText, args), argumentName);
}
public static void ArgumentHasText(string argument, string argumentName)
{
ArgumentNotNull(argument, argumentName);
ArgumentState(argument.Length > 0, argumentName, "Argument cannot be an empty string.");
}
arguments标签在这里似乎有两个意思，哈哈。 - BoltClock