我正在清理一些遗留代码,并且我找到了显式抛出NullReferenceException
的方法(例如:在检查类的某些属性是否为空时,或检查配置时)。由于在空引用的情况下CLR抛出了这种类型的异常,对于明确抛出的应用程序来说,这似乎是一个非常糟糕的异常选择。
我的问题是 - 是否存在任何原因NullReferenceException
对于从代码中明确抛出的异常是一个不错的选择?
答案 0 :(得分:9)
NullReferenceException
的文档暗示您不应该从应用程序中抛出它:
请注意,应用程序抛出ArgumentNullException异常而不是此处讨论的NullReferenceException异常。
而且我确信我已经在其他地方看到了指导(目前找不到任何指导 - >它在这里https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types)你应该避免抛出运行时引发的异常类型(虽然我是即将链接到显示运行时抛出“应用程序”异常的内容)
如果您正在检查方法中的属性,则在继续之前,听起来您可能希望将其替换为InvalidOperationException:
如果调用方法失败是由无效参数以外的原因引起的,则使用InvalidOperationException。
处于方法调用的错误状态听起来像是符合这个定义。
答案 1 :(得分:5)
不,没有理由抛出NullReferenceException
。
您总是有一些有关错误原因的更多信息,因此您应该抛出一个传达该信息的异常。
例如,如果您在不允许的情况下获取空引用作为参数,则会抛出ArgumentException
或ArgumentNullException
。
答案 2 :(得分:2)
答案 3 :(得分:2)
不,NullReferenceException
只应由框架本身抛出。 ArgumentNullException
或InvalidOperationException
是有效的替代方案。
答案 4 :(得分:1)
我假设如果代码没有检查你会得到NullReferenceException(NRE),所以没有。但是我发现有一个应用程序消息可以更好地解释具有内部异常类型NRE或ArgumentExecption的特定函数的调用机制,因为这是导致问题的问题。
答案 5 :(得分:0)
我可以选择那些明确抛出它的意义。首先想到的是在CLR遇到异常之前,在完成许多其他处理之前检查属性。