对于 null 参数，抛出异常与检查 null
哪些因素决定在参数为 null 时抛出异常（例如 if (a is null) throw new ArgumentNullException() ），而不是事先检查参数是否为 null。
我不明白为什么应该抛出异常而不是首先检查 null ？抛出异常方法有什么好处？
这是针对 C#/.NET 的，
谢谢
What factors dictate throwing an exception if argument is null (eg if (a is null) throw new ArgumentNullException() ), as opposed to checking the argument if it is null beforehand.
I don't see why the exception should be thrown rather than checking for null in the first place? What benefit is there in the throw exception approach?
This is for C#/.NET
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
通常，当传递值为 null 但“永远”不应该为 null 的参数时，您会抛出 ArgumentNullException。它是一个用于处理空值的特定 ArgumentException。
通常，如果您知道要获取 null 值作为参数，您会检查 null 并相应地规划方法的其余部分 - 如果不存在记录，通常会创建记录，或者执行与如果不存在则运行的子例程不同的子例程提出了有效的论点。在这种情况下，我通常不使用 ArgumentNullException，因为我计划将 null 作为有效输入。
我仅在确信某个东西到达那里时不应该为 null 时才使用 ArgumentNullException，并且我想记下定义为“无效”的参数。
Generally you throw ArgumentNullException when an argument gets passed who's value is null but should "never" be null. Its a specific ArgumentException for dealing with nulls.
Oftentimes, if you're aware you're going to get null values as args, you check for null and plan the rest of your method accordingly -- often creating records if none exist, or doing a different subroutine than would've ran if a valid argument was present. In this case, I typically don't use ArgumentNullException because I plan on null being a valid input.
I only use ArgumentNullException when I'm positive something shouldn't be null when it gets there, and I want to make note of an argument thats defined as "invalid".
当参数为空时，您的方法可以执行以下三件事之一。它可以抛出异常，可以返回而不执行任何操作，或者可以做出假设并尝试继续。我假设您正在尝试在前两个选项之间进行选择。
由于调用方法始终可以在调用方法之前检查参数，因此可以防止传递无效值。无论您的方法如何处理无效值，都是如此。
当使用无效参数调用您的方法时，它应该通知调用者处理没有继续。您可以通过抛出异常或返回错误值来通知它。如果您检查 null 并且不返回错误值，则调用方法将假定您的方法处理时没有错误。
您希望调用方法如何处理您的方法未处理的情况？如果传递 null 是正常情况，并且应该可以通过调用方法轻松处理，则返回 null 参数的错误是可以接受的。在这种情况下，调用方法要么检查之前的参数，要么检查之后的返回值，选择取决于编写调用方法的人。
如果传递 null 的情况非常罕见，则抛出异常。调用方法可以通过在调用方法之前检查参数来防止异常，就像上面一样。通过抛出异常，可以展开调用堆栈，而无需添加大量代码。
摘要：
如果设置为 null 的参数是例行程序，并且应编写调用方法来处理函数返回而不执行任何操作，则仅返回错误值。如果空参数很少见，并且不能期望调用方法来处理您的方法，那么什么都不做就会抛出异常，因此调用堆栈将被展开。
Your method can do one of three things when an argument is null. It can throw an exception, it can return without doing anything, or it can make assumptions and attempt to continue. I'm assuming you are trying to choose between the first two options.
Since the calling method can always check the arguments prior to calling your method it can prevent invalid values from being passed. This is true regardless of how your method handles invalid values.
When your method is called with invalid arguments it should notify the caller that processing did not continue. You can notify it by throwing an exception or returning an error value. If you check for null and don't return an error value the calling method will assume your method processed with no errors.
How do you want the calling method to handle the case where your method does not process? If passing null is a normal occurrence and should be easily handled by the calling method returning an error on a null argument is acceptable. In this case the calling method either checks the arguments prior or the return value after the choice is up to whoever writes the calling method.
If passing a null is very rare then throw an exception. The calling method can prevent the exception by checking arguments before calling your method just like above. By throwing an exception the call stack can be unwound without having to add lots of code.
Summary:
If an argument set to null is routine and the calling method should be written to handle your function returning without doing anything just return an error value. If a null argument is rare and the calling method can't be expected to handle your method doing nothing throw an exception so the call stack is unwound.
永远不要编写检查空参数然后不执行任何操作的代码。在客户端代码中隐藏错误是非常错误的，当您的 API 没有得到正确使用时，您希望尽可能提供帮助。
ArgumentNullException非常有帮助。
Don't ever write code that checks for a null argument and then does nothing. Hiding bugs in the client code is quite wrong, you want to be as helpful as possible when your API doesn't get used properly.
ArgumentNullException is very helpful.
作为方法编写者，您必须决定是否可以合理地推断调用者通过
null可能意味着什么。如果可以的话，请采取行动。如果不能，请抛出ArgumentNullException来通知调用者他们为您提供了一个您无法使用的值。这是防御性编程——尽可能早地死掉并提供尽可能多的信息，而不是试图在部分有效的状态下跛行，这会变成更微妙（也更难修复）的错误。
As a method writer, you must decide whether you can reasonably infer what the caller may have meant by
null. If you can, take action. If you cannot, throwArgumentNullExceptionto inform the caller they gave you a value you cannot use.It's defensive programming - die as early and as informatively as possible, instead of trying to limp along with partially valid state, which turns into much more subtle (and harder to fix) bugs.
这是关于决定你的方法的契约是什么。如果您希望约定调用者不得传入
null，则在收到异常时必须抛出异常。不要相信来电者永远不会犯这样的错误！ OTOH，如果您希望合同在该论证中不那么严格（无论这意味着什么；要么优雅地不做任何事情，要么采取其他某种行为），那么例外显然是错误的。无论你做什么，记录下来。在向你的方法扔东西之前，给可怜的调用者一个机会把事情做好......
This is about deciding what the contract for your method is. If you want the contract to be that callers must not pass in a
null, you must throw an exception if you get one. Don't trust the caller to never make that mistake! OTOH, if you want the contract to be not quite so restrictive in that argument (whatever that means; either doing nothing gracefully or some other kind of behavior) then an exception is obviously wrong.Whatever you do, document it. Give the poor caller a chance to get it right before throwing things at your method...