考虑配置（在我的例子中是属性）为空的情况。
public Configuration {get;set;}
if (configuration == null)
{
throw NullReferenceException("Blah blah blah..");
}
但是，我在某处读到，“永远不要在代码中抛出空引用异常。NullReferenceException是运行时异常，只能由运行时引发”。
如果它是函数的参数，我想我会使用ArgumentNullException.
那么，在这种情况下应该是什么例外？总的来说，在什么情况下应该抛出什么异常？谷歌搜索了这个但没有令人满意的答案。
InvalidOperationExceptions states -当方法调用对于对象的当前状态无效时引发的异常，我想这不是很合适吗？我同意空引用不是你应该抛出的。
这是另一个常见异常列表。
该建议是正确的，因为空引用异常并没有说明实际错误。
如果该值不允许为空，那么您应该尝试找到一个描述错误的异常。问题不在于引用为空，而是引用为空的根本原因。
如果您找不到任何足够接近的异常类，例如，您可以创建自己的ConfigurationMissingException异常。
当方法调用对于对象的当前状态无效时引发的异常。
这听起来像你的情况。
基本上，如果它与参数无关，并且您想抛出内置异常，您的选择通常归结为两个异常之一。如果您永远无法兑现请求，NotImplementedException是合适的。但如果是配置或状态问题，InvalidOperationException则符合要求。
在什么情况下你不应该抛出异常。它仅在发生意外情况时使用，例如您尝试为配置设置一些null值。但是，如果配置可以null并且已经是，您应该以其他方式处理它。
我认为这里实际上有三种情况：
首先，这可能是由于班级的用户做错事而导致的吗？他们是否忘记先调用或设置某些东西（即他们是否违反了时间依赖性）？
如果是这样，那么我认为适当的例外是InvalidOperationException，带有Message描述如何解决问题的 ，或者您可能想要指定如下所述的代码合同。
其次，这只能由于课堂上的逻辑错误而发生吗？换句话说，无论类的用户如何使用它的公共方法和属性，都应该不会发生这种情况吗？
如果是这样，那么如果您使用的是代码合同，您可以通过以下方式声明是这种情况：
Contract.Assume(configuration != null);
我觉得这要好得多。但是，违规引发的异常是无法捕获的，除非您 catch Exception。这是经过深思熟虑的，也是 IMO 的正确选择。
如果你不使用代码契约，那么你就会被 throwing 困住InvalidOperationException。
第三，如果这个异常是由于程序无法控制的外部因素而自然出现的，如果不存在与问题匹配的异常类型，您可能应该为其编写自定义异常类型。然而，对于这个特定的例子，情况似乎不太可能。我希望它会在其他地方处理。