如果他不期望为空，是否应该检查为空？

上周，我们就在应用程序的服务层中处理null产生了激烈的争论。问题是在.NET上下文中，但在Java和许多其他技术中将是相同的。

问题是：无论什么情况，您是否应该始终检查null并使代码正常工作，还是当意外收到null时让异常冒出？

在我看来，一方面，在您不期望它的地方检查空值（即，没有用户界面来处理它）与编写带有空catch的try块相同。您只是隐藏一个错误。错误可能是代码中的某些内容已更改，并且null现在是预期值，或者存在其他错误，并且将错误的ID传递给该方法。

另一方面，检查空值通常是一个好习惯。此外，如果进行检查，则应用程序可能会继续运行，而只有一小部分功能无效。然后，客户可能会报告一个小错误（例如“无法删除评论”），而不是更严重的错误（例如“无法打开页面X”）。

您遵循哪种做法，您对这两种方法的论点是什么？

更新：

我想添加一些有关我们特殊情况的细节。我们正在从数据库中检索一些对象，并对它们进行了一些处理（比如，建立一个集合）。编写代码的开发人员并不预期该对象可以为null，因此他不包含任何检查，并且在加载页面时出现错误，并且整个页面都没有加载。

显然，在这种情况下，应该进行检查。然后，我们讨论了是否应该检查每个处理的对象（即使不会丢失），以及是否应该静默中止最终的处理。

假设的好处是该页面将继续工作。考虑一下Stack Exchange上不同组（用户，评论，问题）的搜索结果。该方法可以检查是否为空，并中止用户的处理（由于错误为空），但返回“评论”和“问题”部分。该页面将继续工作，只是缺少“用户”部分（这是一个错误）。我们应该尽早失败并中断整个页面，还是继续工作并等待有人注意到“用户”部分丢失了？

问题不仅仅在于您是否应该检查null还是让运行时抛出异常。这是应对这种意外情况的方法。

那么，您的选择是：

• 抛出一个通用异常（NullReferenceException），使其冒泡；如果您自己不进行null检查，这将自动发生。
• 抛出一个自定义异常，从更高层次上描述问题；这可以通过抛出null检查或捕获a NullReferenceException并抛出更具体的异常来实现。
• 通过替换一个合适的默认值进行恢复。

没有一般规则，哪个是最佳解决方案。我个人会说：

• 如果错误条件是代码中严重错误的征兆，则最好是通用异常，也就是说，一开始绝对不允许null值到达那里。这样的异常可能会一直冒泡到您设置的任何错误日志中，以便有人得到通知并修复该错误。
• 如果提供半有用的输出比正确性更重要，则默认值解决方案是很好的，例如，Web浏览器接受技术上不正确的HTML并尽最大努力呈现出合理的效果。
• 否则，我将处理特定的异常并在适当的地方处理它。

恕我直言，尝试处理您不期望的空值会导致代码过于复杂。如果您不希望为null，请抛出ArgumentNullException。当人们检查该值是否为null并尝试编写一些毫无意义的代码时，我感到非常沮丧。同样的情况也适用于SingleOrDefault在某人真正期望时使用（或什至更糟的是获得收藏），Single以及在许多其他情况下（当人们不知道该怎么做）人们清楚地陈述其逻辑的情况。

根据null我的经验进行检查的习惯来自以前的C或C ++开发人员，在这些语言中，如果不进行检查，则很有可能隐藏严重的错误NULL。如您所知，在Java或C＃中，情况有所不同，使用未经检查的null ref null将导致异常，因此只要您在调用方不忽略该错误，该错误就不会被秘密隐藏。因此，在大多数情况下，显式检查null并没有多大意义，并且会使代码过于复杂。这就是为什么我不认为空检查在那些语言中是个好习惯（至少，不是一般而言）。

当然，该规则也有例外，以下是我可以想到的那些例外：

• 您需要一条更好的，易于理解的错误消息，告诉用户错误的空引用出现在程序的哪个部分。因此，您对null的测试只会引发不同的异常，并带有不同的错误文本。显然，这样不会掩盖任何错误。

• 您想使程序“更早失败”。例如，您要检查构造函数参数的空值，否则该对象引用将仅存储在成员变量中，并在以后使用。

• 您可以安全地处理null引用的情况，而没有后续错误的风险，也不会掩盖严重的错误。

• 您希望在当前上下文中使用一种完全不同的错误信号（例如，返回错误代码）

使用断言来测试和指示代码的前提条件/后置条件和不变式。

它使理解代码期望以及期望处理什么变得容易得多。

IMO断言是合适的检查，因为它是：

• 高效（通常不用于发布），
• 简短的（通常是一行）和
• 清除（违反了前提条件，这是编程错误）。

我认为自我记录代码很重要，因此进行检查很不错。防御性的，快速故障的编程使维护方式变得更容易，这通常是大多数时间所花费的时间。

更新资料

精心整理。给最终用户一个在错误下可以很好地运行的应用程序通常是很好的，即尽可能多地显示。健壮性好，因为天堂只知道在关键时刻会破裂。

但是，开发人员和测试人员必须尽快意识到错误，因此您可能希望使用带有钩子的日志记录框架，该钩子可以向用户显示存在问题的警报。该警报可能应该显示给所有用户，但可能会根据运行时环境进行不同的调整。

早期失败，经常失败。null是您可以获得的最佳意外值之一，因为一旦尝试使用它，很快就会失败。其他意外值不太容易检测。由于null每当您尝试使用它时，它都会自动失败，因此我认为它不需要显式检查。

• 检查null应该是您的第二天性

• 您的API将被其他人使用，他们的期望可能与您的期望不同

• 全面的单元测试通常强调需要进行空引用检查

• 检查null并不意味着条件语句。如果您担心空检查会使代码的可读性降低，那么您可能需要考虑.NET代码协定。

• 考虑安装ReSharper（或类似工具）以搜索代码以查找缺少的空引用检查

我将从语义的角度考虑这个问题，即问自己一个空指针或空引用自变量代表什么。

如果函数或方法foo（）的参数x为T类型，则x可以是强制性的或可选的。

在C ++中，您可以将强制性参数传递为

• 一个值，例如void foo（T x）
• 一个引用，例如void foo（T＆x）。

在这两种情况下，您都没有检查NULL指针的问题。所以，在很多情况下，你并不需要一个空指针检查所有强制参数。

如果要传递可选参数，则可以使用指针并使用NULL值指示未提供任何值：

void foo(T* x)

一种替代方法是使用类似

void foo(shared_ptr<T> x)

在这种情况下，您可能要检查代码中的指针，因为x是否包含值或根本不包含值对方法foo（）有所不同。

第三种也是最后一种情况是将指针用作必需 参数。在这种情况下，使用x == NULL调用foo（x）是一个错误，您必须决定如何处理此错误（与越界索引或任何无效输入相同）：

1. 无需检查：是否有错误让它崩溃，并希望该错误足够早地出现（在测试过程中）。如果不是这样（如果您没有足够早地失败），则希望它不会出现在生产系统中，因为用户体验将是他们看到应用程序崩溃。
2. 检查方法开头的所有参数，并报告无效的NULL参数，例如，从foo（）引发异常，然后让其他方法处理它。最好的办法是向用户显示一个对话框，指出该应用程序遇到内部错误并将要关闭。

除了更好的失败方法（向用户提供更多信息）之外，第二种方法的优点是更可能发现错误：每次使用错误的参数调用方法时，程序都会失败方法1该错误仅在执行了取消引用指针的语句后才会出现（例如，如果输入了if语句的右分支）。因此，方法2提供了一种更强的“早期失败”形式。

在Java中，您有较少的选择，因为所有对象都是使用始终为null的引用传递的。同样，如果null表示可选参数的NONE值，则检查null（可能）将是实现逻辑的一部分。

如果null为无效输入，则您将出错，并且我将采用与C ++指针类似的考虑因素。由于在Java中您可以捕获空指针异常，因此，如果方法foo（）取消引用所有执行路径中的所有输入参数（对于小型方法可能经常发生），则上述方法1等同于方法2。

总结

• 在C ++和Java中，检查可选参数是否为null都是程序逻辑的一部分。
• 在C ++中，我将始终检查强制性参数以确保抛出适当的异常，以便程序可以以健壮的方式对其进行处理。
• 在Java（或C＃）中，如果存在为了增强“早期失败”形式而不会抛出的执行路径，我将检查强制性参数。

编辑

感谢Stilgar提供更多详细信息。

就您而言，方法的结果似乎为空。同样，我认为您应该先澄清（并修复）方法的语义，然后才能做出决定。

因此，您有方法m1（）调用方法m2（），而m2（）返回对某个对象的引用（在Java中）或指针（在C ++中）。

m2（）的语义是什么？m2（）是否应始终返回非空结果？如果是这种情况，则空结果是内部错误（在m2（）中）。如果在m1（）中检查返回值，则可以得到更可靠的错误处理。如果不这样做，迟早会有例外。也许不吧。希望在测试期间而不是部署之后引发异常。问题：如果m2（）永远不要返回null，为什么它返回null？也许它应该引发异常？m2（）可能是越野车。

另一种选择是，返回null是方法m2（）的语义的一部分，即它具有可选的结果，该结果应记录在该方法的Javadoc文档中。在这种情况下，可以为空值。方法m1（）应该将其检查为其他任何值：这里没有错误，但可能检查结果是否为null只是程序逻辑的一部分。

我的一般方法是永远不要测试您不知道如何处理的错误情况。这样，在每个特定实例中需要回答的问题就变成了：在出现意外值的情况下，您可以做一些合理的事情null吗？

如果可以通过替换另一个值（例如，空集合或默认值或实例）来安全地继续操作，则一定要这样做。@Shahbaz在《魔兽世界》中将一个图像替换为另一个图像的例子属于该类别。图像本身可能只是装饰，没有功能影响。（在调试版本中，我将使用尖叫的颜色来引起注意替换已发生的事实，但这在很大程度上取决于应用程序的性质。）但是，请记录有关该错误的详细信息，以便您知道该错误的发生。否则，您将隐藏您可能想知道的错误。对用户隐藏它是一回事（同样，假设处理可以安全地继续）；向开发人员隐藏它是另一回事。

如果在存在null值的情况下不能安全继续，则失败并显示明智的错误；通常，当操作明显无法成功时，我宁愿尽快失败，这意味着检查前提条件。有时您不希望立即失败，而要尽可能长地推迟失败；例如，在与密码相关的应用程序中会出现这种情况，在这种应用程序中，旁通道攻击可能会泄露您不想要的信息。最后，让错误冒泡到某个通用错误处理程序，该错误处理程序随后记录相关的详细信息，并向用户显示一个不错的（无论多么不错）错误消息。

还值得注意的是，测试/ QA /调试版本与生产/发行版本之间的正确响应可能会非常不同。在调试版本中，我会尽力而为地尽早失败，并给出非常详细的错误消息，以使其完全清楚地表明存在问题，并允许事后确定确定需要解决的问题。当生产版本遇到安全可恢复的错误时，可能应该支持恢复。

当然NULL不是预期，但总有虫子！

我相信您应该检查您NULL是否不期望它。让我给您示例（尽管它们不是Java语言）。

• 在《魔兽世界》中，由于存在一个错误，开发人员之一的形象出现在了许多对象的立方体上。想象一下，如果图形引擎不期望 NULL指针，那么将会发生崩溃，而对于用户而言，它却不是那么致命（甚至很有趣）。至少，您不会意外失去连接或任何保存点。

  这是一个检查NULL防止崩溃的示例，该案例已被静默处理。

• 想象一下一个银行出纳员程序。该接口进行一些检查，并将输入数据发送到基础部分以执行汇款。如果核心部分预计不接收NULL，然后在界面中的错误可以在交易中间产生问题，可能还有一些钱迷路（或更糟的是，重复）。

  “问题”是指崩溃（如崩溃崩溃（例如，程序是用C ++编写的），而不是空指针异常）。在这种情况下，如果遇到NULL，则事务需要回滚（如果不对NULL进行变量检查，那当然是不可能的！）

我敢肯定你知道这个主意。

检查函数自变量的有效性不会使代码混乱，因为这是对函数顶部的几次检查（不散布在中间），并大大提高了健壮性。

如果必须在“程序告诉用户它已失败并正常关闭或回退到可能创建错误日志的一致状态”和“访问冲突”之间进行选择，您是否会选择第一个？这意味着每个功能都应该为有缺陷的代码调用做好准备，而不是仅仅因为错误总是存在而期望一切都正确。

如其他答案所指出的如果你没想到的话NULL，用投掷来弄清楚ArgumentNullException。我认为，在调试项目时，它可以帮助您更快地发现程序逻辑中的错误。

因此，您将要发布软件，如果您恢复了这些NullRefrences检查，就不会错过任何软件逻辑，这可以确保不会弹出严重的错误。

另一点是，如果NULL检查功能的参数，则可以决定该功能是否正确。如果不是，请找到对函数的所有引用，然后在将参数传递给函数之前检查可能导致空引用的情况。

null系统中的每一个都是一个等待被发现的滴答定时炸弹。null在代码与不受控制的代码进行交互的边界处进行检查，并禁止null在自己的代码内进行。这使您摆脱了问题，而不必天真地信任外来代码。使用异常或某种Maybe/ Nothing类型代替。

尽管最终会抛出一个空指针异常，但它通常会与您获得空指针的位置相距甚远。帮自己一个忙，并至少记录下您尽快混入空指针这一事实，并缩短修复错误的时间。

即使您现在不知道该怎么办，记录事件也会在以后节省您的时间。也许获得票证的人将能够利用节省的时间来找出正确的响应。

由于Fail early, fail fast如@DeadMG（@empi）所述，由于Web应用程序必须能够在错误下正常运行，因此不可行，因此应执行规则

没有日志就不会捕获异常

因此，作为开发人员，您可以通过检查日志来了解潜在的问题。

如果您使用的是log4net或log4j之类的日志记录框架，则可以设置一个附加的特殊日志记录输出（aka附加程序），向您发送错误和致命错误消息。让您随时了解情况。

[更新]

如果页面的最终用户不应该知道该错误，则可以设置一个追加程序，以向您发送错误消息和致命错误消息，并及时通知您。

如果页面的最终用户可以看到隐秘的错误消息，则可以设置一个附加程序，将页面处理的错误日志放在页面末尾。

无论您如何使用日志记录，如果吞下异常，程序都会继续处理有意义的数据，并且吞咽不再安静。

这个问题已经有了不错的答案，可能是它们的补充：我更喜欢代码中的断言。如果您的代码只能与有效对象一起使用，而螺母只能为null，则应声明null值。

在这种情况下的断言会使任何单元和/或集成测试失败，并显示准确的消息，因此您可以在生产之前非常迅速地确定问题。如果这样的错误通过了测试并进入生产阶段（应该取消激活断言），您将收到NpEx和一个严重的错误，但是比一些较小的错误要好得多，后者会更加模糊并在其他地方弹出代码，并且修复起来会更昂贵。

此外，如果有人必须使用您的代码断言，则还可以告诉他有关您在设计/编写代码期间所做的假设（在这种情况下：嘿，伙计，必须显示此对象！），这使维护更加容易。

我通常检查是否存在null，但会抛出一个异常来“处理”意外的null，该异常给出了有关null发生位置的更多详细信息。

编辑：如果在不希望出现某些错误的情况下得到null，则程序应终止。

这取决于异常的语言实现。异常使您可以采取一些措施，以防止损坏数据或在系统进入意外状态时干净地释放资源。这与错误处理不同，后者是可以预见的。我的理念是，应尽可能减少异常处理。是噪音 通过处理异常，您的方法可以做任何合理的事情吗？可以恢复吗？它可以修复或防止进一步的损坏吗？如果您只是要捕获异常，然后从方法中返回或以其他无害的方式失败，那么捕获异常确实没有意义。您只会增加方法的噪声和复杂性，并且可能在设计中隐藏了故障源。在这种情况下，我会让故障冒泡并被外部循环捕获。如果您可以执行某些操作，例如修复对象或将其标记为损坏，或者释放一些关键资源（例如锁定文件）或通过完全关闭套接字，则可以很好地使用异常。如果您实际上希望NULL作为有效的边缘情况频繁出现，那么您应该在常规逻辑流程中使用if-the-else或switch-case语句或其他任何方式来处理此问题，而不使用异常处理。例如，以某种形式禁用的字段可以设置为NULL，这与表示保留为空白的字段的空字符串不同。这是您必须使用良好判断力和常识的领域。我从未听说过在每种情况下如何处理此问题的良好经验法则。如果您可以执行某些操作，例如修复对象或将其标记为损坏，或者释放一些关键资源（例如锁定文件）或通过完全关闭套接字，则可以很好地使用异常。如果您实际上希望NULL作为有效的边缘情况频繁出现，那么您应该在常规逻辑流程中使用if-the-else或switch-case语句或其他任何方式来处理此问题，而不使用异常处理。例如，以某种形式禁用的字段可以设置为NULL，这与表示保留为空白的字段的空字符串不同。这是您必须使用良好判断力和常识的领域。我从未听说过在每种情况下如何处理此问题的良好经验法则。如果您可以执行某些操作，例如修复对象或将其标记为损坏，或者释放一些关键资源（例如锁定文件）或通过完全关闭套接字，则可以很好地使用异常。如果您实际上希望NULL作为有效的边缘情况频繁出现，那么您应该在常规逻辑流程中使用if-the-else或switch-case语句或其他任何方式来处理此问题，而不使用异常处理。例如，以某种形式禁用的字段可以设置为NULL，这与表示保留为空白的字段的空字符串不同。这是您必须使用良好判断力和常识的领域。我从未听说过在每种情况下如何处理此问题的良好经验法则。

Java在其异常处理实现中使用“检查的异常”失败，其中必须在方法的“ throws”子句中捕获或声明方法中使用的对象可能引发的所有可能的异常。这与C ++和Python相反，您可以根据需要选择处理异常。在Java中，如果您修改方法的主体以使其包含可能引发异常的调用，则您可能会选择添加显式处理以处理可能不关心的异常，从而给代码增加噪音和复杂性，或者您必须将该异常添加到您正在修改的方法的“ throws”子句中，这不仅会增加噪音和混乱，而且会更改方法的签名。然后，无论使用哪种方法来处理您的方法现在可能引发的新异常，或者必须将异常添加到这些方法的“ throws”子句中，从而触发代码更改的多米诺效应，您都必须转到修改代码。“捕获或指定需求”必须是Java最令人讨厌的方面之一。RuntimeExceptions的异常异常和针对此设计错误的官方Java合理化是la脚。

最后一段与回答您的问题无关。我只是讨厌Java。

-诺亚