对 null 进行多少次检查是合适的？答案

【问题标题】：How many checks against null is appropriate?对 null 进行多少次检查是合适的？
【发布时间】：2013-01-17 17:16:48
【问题描述】：

当一个变量缺少一个字段并且用户看到这个或那个变量没有这个或那个属性的警告时，我遇到了这个问题。在简单的情况下，它非常简单。

if(field)
  doSomething(field.subField);

但是，在经验情况下，我发现自己陷入了这种荒谬的过度检查。

if(!data 
  || !data.records 
  || !data.records[0] 
  || !data.records[0].field 
  || !data.records[0].field.id)
    return null;
doSomething(data);

我的意思是，来吧 - 如果我是水管工，而不是开发人员，管道式的东西看起来像。所以，我有一种非常强烈的感觉，我的支票虽然足够，但可能有点太过分了。 JS 中是否有关于何时执行检查的约定？

【问题讨论】：

如果你需要经常这样做，你的代码可能比你想象的要多。
有一个库可能会有所帮助：github.com/jclem/steeltoe
改用try/catch 怎么样？
+1 @Blazemonger。我认为 Python 有理由支持它，但我不记得它叫什么了。
从您的代码看来，您正在验证 JSON 或类似结构。如果您确实需要这样做，我建议将您的验证代码重构为一个单独的函数。

标签： javascript coding-style

【解决方案1】：

我只是提出一个有争议的意见。

在 JavaScript 中，不要在实际不应该发生的地方检查 null 值。换句话说，您检查每个嵌套属性是否为空的想法有点过头了，只会使您的脚本复杂化。

根据我的经验，我学会了让脚本错误发生。这对于编写 C 代码或数据库代码的人来说有点违反直觉，其中未处理的 null 可能会使服务器崩溃或损坏数据，但是在脚本世界中，最好尽早发现您的错误。如果您的页面继续加载而没有任何意外发生的迹象，那么稍后当用户单击按钮或提交表单时，它只会以奇怪的错误形式出现。

我的建议：

检查null仅如果您愿意对此做点什么。如果您的 Web 服务在出现问题时可能会返回 null，请检查并显示错误消息。如果你得到一个非空值，假设它是一个有效值并继续。没有理由在你的整个脚本中乱扔空检查，这实际上不会给你的程序带来任何真正的好处。

【讨论】：

当客户厌倦了收到错误消息并判断每个错误消息如世界末日时，就会出现问题。现在，我已经接管了别人的代码，所以我不得不带着“又出现一个错误”这个常数离开——我的头上一片乌云。不过，总的来说，我喜欢你的想法。我可能只是抛出一个 try/catch 并只向我报告错误，从而避免用户被错误消息所困扰。谢谢！
大多数浏览器也支持window.onerror事件，所以你可以捕获它并安静地登录。
不知道。你的意思是我可以去window.onerror = function(){ ... } inside window.onload 方法？！还是应该将其放置在与它平行的同一水平面上？是否保证捕获所有错误或需要我仍然使用 try-catch？
是的，最好与它平行。我不知道它是否保证捕获所有错误，每个浏览器对它的支持不同。如果您需要捕获所有内容，您可能需要使用try/catch。

【解决方案2】：

通常您会确保如果一个对象存在，它总是具有一组使其可用的基本属性。

例如，如果变量data 有一个值，那么它将是一个具有records 属性的对象，该属性始终是一个数组，即使它是空的。如果数组包含任何内容，则它应该始终是具有field 属性的对象，即始终具有id 属性的对象。这会将检查减少到：

if (!data || data.records.length == 0) {
  return null;
}

【讨论】：

我喜欢这个主意。然而，正如我在下面评论的那样，我很高兴在一个不太精明的编码人员之后接管了这个项目，而且客户不愿意为重新开发付费。他们只支付我们“修复和修补”的费用。回想起来，我不应该同意这个项目，但我在想“嘿，这只是 JS，修复一些 bug 有多难”。现在我像个混蛋一样站在这里……
根据我的经验，Javascript 是最容易出现疯狂方法、疯狂代码、功能误解的环境，当然如果...很难调试。
如果records 未定义，此方法将导致未捕获的错误。如果您确实需要捕获所有错误，请使用try/catch。
@KubaHoluj：你没有抓住重点。如果您使用答案中提供的方法，records 属性永远不会未定义。