显式抛出NullReferenceException的原因？

Question

我正在清理一些遗留代码，并且我找到了显式抛出NullReferenceException的方法（例如：在检查类的某些属性是否为空时，或检查配置时）。由于在空引用的情况下CLR抛出了这种类型的异常，对于明确抛出的应用程序来说，这似乎是一个非常糟糕的异常选择。

我的问题是 - 是否存在任何原因NullReferenceException对于从代码中明确抛出的异常是一个不错的选择？

Answer 1

NullReferenceException 的文档暗示您不应该从应用程序中抛出它：

  

请注意，应用程序抛出ArgumentNullException异常而不是此处讨论的NullReferenceException异常。

而且我确信我已经在其他地方看到了指导（目前找不到任何指导 - ＆gt;它在这里https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types）你应该避免抛出运行时引发的异常类型（虽然我是即将链接到显示运行时抛出“应用程序”异常的内容）

---

如果您正在检查方法中的属性，则在继续之前，听起来您可能希望将其替换为InvalidOperationException：

  

如果调用方法失败是由无效参数以外的原因引起的，则使用InvalidOperationException。

处于方法调用的错误状态听起来像是符合这个定义。

Answer 2

不，没有理由抛出NullReferenceException。

您总是有一些有关错误原因的更多信息，因此您应该抛出一个传达该信息的异常。

例如，如果您在不允许的情况下获取空引用作为参数，则会抛出ArgumentException或ArgumentNullException。

Answer 3

MSDN说：

  

请注意，应用程序抛出ArgumentNullException异常   而不是这里讨论的NullReferenceException异常。

所以你的问题的答案可能是“不”。

Answer 4

不，NullReferenceException只应由框架本身抛出。 ArgumentNullException或InvalidOperationException是有效的替代方案。

Answer 5

我假设如果代码没有检查你会得到NullReferenceException（NRE），所以没有。但是我发现有一个应用程序消息可以更好地解释具有内部异常类型NRE或ArgumentExecption的特定函数的调用机制，因为这是导致问题的问题。

Answer 6

我可以选择那些明确抛出它的意义。首先想到的是在CLR遇到异常之前，在完成许多其他处理之前检查属性。