抛出异常vs检查null，空参数

如果参数为null（例如，如果（a为null）抛出新的ArgumentNullException（）），那么什么因素决定抛出异常，而不是先检查参数是否为null。抛出异常vs检查null，空参数

我不明白为什么应该抛出异常而不是首先检查null？抛出异常方法有什么好处？

这是C＃/。NET

感谢

来源

2010-03-26 dotnetdev

当你说事先检查参数时，能否澄清你的意思？你想让调用者检查null吗？ – 2010-03-26 22:24:40

当参数为null时，您的方法可以执行以下三件事之一。它可以抛出异常，不做任何事情就可以返回，也可以做出假设并尝试继续。我假设你正试图在前两个选项之间进行选择。

由于调用方法始终可以在调用方法之前检查参数，因此可以防止传递无效值。无论您的方法如何处理无效值，情况都是如此。

当你的方法被无效参数调用时，它应该通知调用者处理没有继续。您可以通过抛出异常或返回错误值来通知它。如果您检查null并且不返回错误值，则调用方法将假定您的方法没有错误地处理。

你想如何调用方法来处理你的方法不处理的情况？如果传递null是正常情况，并且应该很容易通过调用方法处理，则返回null参数上的错误是可以接受的。在这种情况下，调用方法要么先检查参数，要么在选择由编写调用方法的人决定后的返回值。

如果传递一个空是非常罕见的，然后抛出异常。调用方法可以在调用方法之前通过检查参数来防止异常，就像上面一样。通过抛出异常，可以解除调用堆栈而无需添加大量代码。

摘要：
如果设置为null的参数是例程，并且调用方法应该被写入来处理函数返回而不执行任何操作，则返回错误值。如果一个null参数很少，并且调用方法不能期望处理你的方法，那么就不会抛出异常，从而调用堆栈被解除。

来源

2010-03-26 22:41:14

作为一种方法的作家，你必须决定是否可以合理地推断什么来电者可通过null意味着。如果可以的话，采取行动。如果你不能，扔ArgumentNullException通知他们给你一个价值，你不能使用的来电者。

它的防御性编程 - 尽可能早地尽可能地提供信息，而不是试图与部分有效的状态一起跛行，这会变得更加微妙（并且更难修复）错误。

来源

2010-03-26 21:55:40

通常在传递参数时抛出ArgumentNullException谁的值为空，但应该“从不”为空。它是一个处理空值的特定ArgumentException。

很多时候，如果你意识到你会得到空值作为参数，你检查null并相应地计划你的方法的其余部分 - 通常会创建记录（如果不存在的话）或者执行不同的子例程如果有一个有效的论点出现，就跑了。在这种情况下，我通常不使用ArgumentNullException，因为我计划将null作为有效输入。

我只使用ArgumentNullException当我积极的东西不应该为null时，它到达那里，我想记录一个参数定义为“无效”。

来源

2010-03-26 22:02:19

有任何现实世界的例子吗？谢谢。 – dotnetdev 2010-03-26 22:27:44

我通常使用的例子是，一个asp.net解决方案，只应通过另一页面内的链接访问内的页的，这需要一个特定的请求参数存在。我总是假设它不会是空的，但通常没有谁认为在网页地址手动输入到那里“更快”，不明白如何才能处理页面的代码业务用户 - 在这种情况下，我会在需要请求参数存在的方法内抛出一个参数nullexception。 – 2010-03-29 14:38:47

永远不要编写检查空参数然后什么都不做的代码。隐藏客户端代码中的错误是非常错误的，当您的API无法正确使用时，您希望尽可能地提供帮助。

ArgumentNullException是很有有帮助。

来源

2010-03-26 22:38:48

关于一个Null参数，例如当且仅当合约所说的人会做的时候，一个空的清单才是合适的。某些.net方法的确如此（例如Delegate.Combine）。 – supercat 2011-02-01 17:59:40

这是关于决定为您的方法的合同是什么。如果你想在合同被调用者不得以null传球，你必须如果你得到一个抛出异常。不要相信来电者永远不会犯这个错误！ OTOH，如果你想在合同中并不那么在参数限制（这意味着什么;无论是优雅的无所作为或一些其他类型的行为），那么一个异常显然是错误的。

不管你做什么，记载它。给可怜的来电者一个机会，在把东西扔在你的方法之前，把它弄好......

来源

2010-03-26 22:51:14

抛出异常vs检查null，空参数

回答

相关问题