这是一个开放性问题，但我想通过良好的异常处理实践来提高我的技能，具体来说就是什么时候需要检查 null 值。
我大多数情况下都知道何时需要检查 null 值，但必须承认有一半的时间我并不知道，这让我很困扰。我知道整型不能设置为 null，除非使用可空整型。我知道字符串可以设置为 null 或空值，因此可以检查 IsNullOrEmpty。
显然，在构造函数中，您也要添加显式检查。这是必须的。我认为，每当将数组、通用对象或其他对象传递到可能设置为 null 的方法中时，您应该检查 null 值，对吗？
但是，异常处理还有更多内容。例如，我不知道什么时候总是需要在代码中显式检查和抛出 null 引用异常。如果我有传入参数，通常情况下很简单，但总会有一些情况让我自问：是否需要显式抛出 null 异常？
我没有具体的例子，但想知道是否有一个好的参考资料，真正讨论与异常处理相关的内容，例如何时抛出异常（在方法、类中等）。
应该避免抛出 NullReferenceException。如果参数为 null，则应抛出 ArgumentNullException。
我倾向于在公共/受保护的方法中对所有引用类型参数进行空值检查。对于私有方法，如果您确定所有调用都将始终具有有效数据，则可以省略检查。
除非您使用了代码契约，否则我建议对任何公共/受保护成员检查参数 - 并明确记录它们是否可以为空。对于私有/内部方法，这变成了验证自己的代码而不是别人的问题... 在这一点上需要做出判断。
我有时会使用一个帮助扩展方法来实现这个目的，这样我就可以写：
public void Foo(string x, string y, string z)
{
x.ThrowIfNull("x");
y.ThrowIfNull("y");
// Don't check z - it's allowed to be null
// Method body here
}
ThrowIfNull 方法将抛出一个带有适当名称的 ArgumentNullException 异常。
在进行任何其他调用之前显式检查，您可以知道如果抛出异常，就不会发生其他事情，因此您不会出现损坏状态。
我承认，在我确定第一个调用将执行相同检查的情况下，我会省略这样的检查 - 例如，如果它是一个重载函数依赖于另一个函数。
使用代码合约，我会这样写:
public void Foo(string x, string y, string z)
{
Contract.Requires(x != null);
Contract.Requires(y != null);
// Rest of method here
}
ContractException 而不是 ArgumentNullException，但所有信息仍然存在，除了可能需要处理第三方错误外，没有人应该显式地捕获 ArgumentNullException。当然，是否允许空值完全取决于情况。防止 null 值进入您的世界确实使某些事情变得更容易，但与此同时，null 值本身也可以很有用。我检查null的经验法则如下：
早期通知null参数（靠近错误点）比远离错误点发生的随机NullReferenceExceptions更好。
您可以使用实用程序方法来清理典型的if( arg == null ) throw new ArgumentNullException(...);结构。您可能还想了解C# 4.0中的代码契约作为改进代码的一种方式。代码契约执行静态和运行时检查，可以帮助甚至在编译时识别问题。
class A
{
private string _Name
public string Name
{
get { return _Name; }
set
{
if (value == null)
throw new ArgumentNullException("Name");
_Name = value;
}
}
public A(string name)
{
//Note the use of property with built in validation
Name = name;
}
}
我更喜欢使用静态模板方法来检查输入约束。一般的格式可能是这样的：
static class Check {
public static T NotNull(T arg) {
if( arg == null ) throw new ArgumentNullException();
}
}
this.instanceMember = Check.NotNull(myArgument);
当我开始使用.Net 4时，我可能会转换为代码合同，但在那之前这个方法可以使用。顺便说一下，您可以在以下网址找到我使用的Check类的更完整定义：
取决于你的方法/ API / 库/框架类型。我认为对于私有方法来说，除非它们属于断言方法，否则不检查空值是可以的。
如果您编写的代码充满“非空”测试或“if”语句，代码将难以阅读。
定义客户端可能通过提交错误/空/ null 参数来搞砸您的代码的区域。如果您知道在哪里，则可以划定检查空值的线。就像现实生活中的安全一样，在您的 API 入口点执行此操作。
想象一下，如果每分钟都要在电影院展示您的票，那么每场电影都会很糟糕。
null，并抛出ArgumentNullException。（当然，如果null是有效的参数，则除外。）如果我不这样做，调用者将会得到一个NullReferenceException，这基本上意味着“你调用的代码是一个有缺陷的混乱”。对于私有代码，我宁愿使用Debug.Assert而不是抛出异常。在调试版本中，它具有相同的错误报告功能，在发布版本中，错误永远不会发生。 - Joren