检查“null”
C# 是否有一些经验法则或编码约定约定来处理可能的 null 参数？
例如，我正在编写一个自定义方法，它检索 byte[] data 参数。
public static string ConvertDataToMyOwnAndCustomString(byte[] data) { ... }
现在 - 如果传递的 data 为 null，我该怎么办？
我应该保持原样，以便可能出现 NullReferenceException< /代码>发生？或者我应该写一张支票并做这样的事情：
if (data == null) return null;
Does C# has some rule of thumb or a coding convention contract, which handles the possible null argument?
As an example, I'm writing a custom method, which retrieves a byte[] data parameter.
public static string ConvertDataToMyOwnAndCustomString(byte[] data) { ... }
Now - what should I do if the passed data is null?
Should I leave it as it is so that a possible NullReferenceException occurs? Or should I write a check and do something like this:
if (data == null) return null;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
则普遍接受的模式是抛出
ArgumentNullException如果客户端将
null传递给您的方法确实是一个错误， 。如今，您甚至可以通过代码契约来强制执行该要求：当然，可能很可能
null对于您的方法来说不是错误。不过，这由您决定，而不是我们。但不要返回null来向您的客户端表明发生了错误。The generally accepted pattern is to throw an
ArgumentNullExceptionif it is indeed an error for clients to be passing
nullto your method. These days, you can even enforce the requirement through a Code Contract:Of course, it might very well be the case that
nullis not an error for your method. That's for you to decide though, not us. But don't returnnullto indicate to your client that an error occurred.我认为最常见的模式是：
I think the most common pattern is:
这真的完全取决于。这个方法在哪里？多久重复使用一次？它仅适用于这个应用程序，还是它是将再次使用的代码库的一部分？
如果要使用它，特别是由其他应用程序/开发人员使用，那么我仍然会测试数据是否为 null，但随后我会抛出异常。你不希望它悄无声息地窒息。
如果这是一种一次性方法，用于肯定永远不会被重用或重新访问的代码，您可以只测试
null并返回null。但请记住，只有当您知道结果时，这才是合适的。如果其他应用程序或其他开发人员有机会使用它，我会测试null然后抛出异常（很可能是ArgumentNullException）。It really all depends. Where does this method live? How often will it be reused? Is it only for this application, or is it part of a code library that will be utilized again?
If it is going to be used, especially by other applications/developers then I would still test for data being
null, but then I would throw an exception. You don't want it to choke silently.If this is a one-off method that is for code that will surely never be reused or revisited, you could just test for
nulland returnnull. Remember, though, this is only appropriate because you know of the outcome. If there is any chance some other application will use this, or another developer, I'd test fornullthen throw an exception (most likely anArgumentNullException).杰森和克里斯托弗的答案是正确的。我只是想补充一下；
如果您可能会为该参数获取
null，但不是异常情况，则不应抛出异常，而应返回适当的值 - 通常为null本身有效。例如，对于某些模型绑定系统，缺少文本值可能会导致
null作为参数传递。这种情况可能是一个错误，但不是“异常”错误。Jason and Christopher's answers are correct. I just want to add to them;
If it is likely and not an exceptional condition that you could get
nullfor that parameter, you should not throw an exception, but instead return an appropriate value - very often,nullitself works.For example, with some systems of model binding, a missing text value might result in a
nullbeing passed as a parameter. Such an occurrence might be an error, but not an 'exceptional' one.