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

#1 楼

问题不仅仅在于您是否应该检查null还是让运行时抛出异常。

那么，您的选择是：


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

没有通用的规则一种是最好的解决方案。我个人会说：


如果错误条件表明代码中存在严重错误，则通用异常最好，也就是说，永远不应该将null值设为首先可以到达那里。这样的异常可能会一直扩展到您设置的任何错误日志中，以便有人得到通知并修复该错误。
如果提供半有用的输出比正确性更重要，则默认值解决方案是很好的，例如网络浏览器，它接受技术上不正确的HTML并尽最大努力呈现出来。
否则，我将使用特定的异常并在适当的地方进行处理。

#2 楼

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

#3 楼

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

当然，该规则有例外，以下是我认为的例外作者：


您想要一个更好的，易于理解的错误消息，告诉用户在程序的哪个部分中出现了错误的空引用。因此，您对null的测试只会引发不同的异常，并带有不同的错误文本。显然，这样不会掩盖任何错误。
您想让程序“更早地失败”。例如，您要检查构造函数参数的null值，否则对象引用将仅存储在成员变量中，以后再使用。
您可以安全地处理null ref的情况，而无需具有后续故障的风险，并且不会掩盖严重错误。
您希望在当前上下文中使用完全不同的错误信号（例如，返回错误代码）

#4 楼

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

它使理解代码期望和期望处理的内容变得更加容易。 />断言（IMO）是合适的检查方法，因为它有效：


高效（通常不用于发布），
简短（通常为一行）和
清除（违反先决条件，这是一个编程错误）。

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

Update

详细说明。通常最好向最终用户提供可以在错误（即尽可能多地显示）下运行的应用程序。健壮性很好，因为天堂只知道在关键时刻会破裂。

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

#5 楼

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

#6 楼

检查空值应该是您的第二天性
您的API将被其他人使用，并且他们的期望可能与您的不同
全面的单元测试通常会强调需要空值引用check
检查null并不意味着条件语句。如果您担心空检查会降低代码的可读性，那么您可能需要考虑.NET代码协定。
考虑安装ReSharper（或类似工具）以在代码中搜索缺失的空引用检查

#7 楼

我的一般方法是永远不要测试您不知道如何处理的错误情况。然后，在每个特定实例中需要回答的问题变成：在出现意外的null值的情况下，您可以做一些合理的事情吗？例如默认值或实例），那么请务必这样做。 @Shahbaz在《魔兽世界》中将一个图像替换为另一个图像的例子属于该类别。图像本身可能只是装饰，没有功能影响。 （在调试版本中，我将使用尖叫的颜色来引起注意替换已发生的事实，但这在很大程度上取决于应用程序的性质。）但是，请记录有关该错误的详细信息，以便您知道该错误的发生。否则，您将隐藏您可能想知道的错误。对用户隐藏它是一回事（同样，假设处理可以安全地继续）；

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

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

#8 楼

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

如果函数或方法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)

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

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


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

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

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

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





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

EDIT

感谢Stilgar的帮助有关详细信息。

您的情况似乎是方法的结果为null。同样，我认为您应该先确定（并修复）方法的语义，然后再做出决定。

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

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

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

#9 楼

肯定不会出现NULL，但是总会有bug！

我相信您应该检查NULL是否不期望它。让我给你举个例子（尽管它们不是用Java编写的）。



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

这是一个检查NULL防止崩溃的情况，该情况被静默处理。 >

想象一个银行出纳员程序。该接口进行一些检查，并将输入数据发送到基础部分以执行汇款。如果核心部分不希望收到NULL，那么界面中的错误可能会导致交易出现问题，中间的一些钱可能会丢失（或更糟的是重复）。

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


您就会明白。

检查函数参数的有效性不会使您的代码混乱，因为这是对函数顶部的几次检查（中间没有进行检查），并且大大增加了坚固性。

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

#10 楼

如其他答案所示，如果您不期望NULL，请抛出ArgumentNullException以使其清楚。我认为，在调试项目时，它可以帮助您更快地发现程序逻辑中的错误。

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

另一点是，如果对函数的参数进行NULL检查，然后，您可以确定该功能是否是执行此操作的正确位置；如果不是，请找到对函数的所有引用，然后在将参数传递给函数之前检查可能导致空引用的情况。

#11 楼

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

#12 楼

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

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

#13 楼

由于@DeadMG（@empi）指出的Fail early, fail fast是不可行的，因为Web应用程序必须能够在错误下正常运行
，您应该强制执行规则

不进行日志记录就不能捕获异常

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

如果您使用的是log4net或log4j之类的日志记录框架，则可以设置其他特殊的日志记录输出（又称为附加器）将错误和致命错误邮寄给您。因此，您可以随时了解最新信息。

[更新]

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

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

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

#14 楼

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

这种情况下的声明将使任何单元和/或集成测试失败，并显示准确的消息，因此您可以在生产前迅速确定问题所在。
如果这样的错误通过测试并进入生产阶段（应取消激活断言），您将收到NpEx和一个严重的错误，但这是更好，而不是一些小错误，这些小错误会更加模糊并在代码中的其他地方弹出，并且修复起来会更加昂贵。在设计/编写代码时所做的假设（在这种情况下：嘿，伙计，必须显示此对象！），这使维护更加容易。

#15 楼

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

编辑：如果在不期望的情况下得到null一件事不对劲-程序应该死了。

#16 楼

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

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

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

-
诺亚