“提前失败”的表达是什么意思，你想什么时候这样做？答案

【问题标题】：What does the expression "Fail Early" mean, and when would you want to do so?“提前失败”的表达是什么意思，你想什么时候这样做？
【发布时间】：2011-02-17 22:22:17
【问题描述】：

“提前失败”是什么意思，在什么情况下这种方法最有用，什么时候避免这种方法？

【问题讨论】：

我阅读了您的问题并认为这是一个大多数人都知道的简单问题。事实证明，至少有三个人有错误的想法......所以+1我猜是为了一劳永逸地记录正确的定义。
@NomeN：我决定问这个问题是因为当我提供答案 stackoverflow.com/questions/2800099/options-fetch-i-dont-get-it/… 时，我发现 Stack Overflow 中没有很好地描述“早期失败”。这并不意味着公然的声誉收获（这只是一个额外的奖励！）

标签： fail-fast-fail-early

【解决方案1】：

本质上，fail fast（又名fail early）是对你的软件进行编码，当出现问题时，软件会失败如下尽快和尽可能显眼，而不是试图在可能不稳定的状态下继续。

快速失败
吉姆·肖尔
由 Martin Fowler 编辑
http://www.martinfowler.com/ieeeSoftware/failFast.pdf

...
幸运的是，有一个简单的技术将大大减少这些数量您的软件中的错误。不会减少错误的总数，在至少一开始不会，但它会让大多数缺陷更容易找到。

技术是建立你的软件“快速失败”。

立即和可见的失败

有些人建议制作您的软件通过工作而健壮自动解决问题。这会导致软件“缓慢失败”。该程序在一个之后继续工作错误，但后来以奇怪的方式失败。

快速失败的系统恰恰相反：当出现问题时，立即失败并且明显。快速失败是不直观的技术：“立即明显地失败” 听起来它会让你的软件更脆弱，但它实际上使它更健壮。错误更容易找到和修复，因此更少进入生产。
...

还要注意 fail-fast iterator 的相关概念 - 一个迭代器，在对迭代器外部的集合进行某些修改后，会尽快抛出而不是在潜在的不稳定中继续，或者非确定性状态。

【讨论】：

通过一个反例来解释，不会“快速失败”的东西是大多数网络浏览器和 HTML。考虑这个无效的 HTML：<div><b>Bold Text!</div> 它缺少 </b>，但网络浏览器选择做与“早期失败”相反的事情，试图从问题中恢复并希望它不会让事情变得更糟。在他们的情况下，这是一条明智的选择。但是，当您编写代码（而不是可视化表示层）时，追求正确性可能是更好的策略。
@Darien “在他们的情况下，这是一条明智的选择。” — 该声明（称为“稳健性原则”或“Postel 定律”）是在没有支持证据的情况下提出的，此后一直是 heavily criticised。事实上，几乎可以肯定这是错误的。至少，它使维护 Web 浏览器代码库的成本不必要地增加，并阻止了这些资源被用于更有价值的目的。
@KonradRudolph：确实，如果所有浏览器在不平衡的<b> 标签上都失败了，我们就不会有带有损坏<b> 标签的网站，因为Web 开发人员会在开发过程中注意到它。不幸的是，一旦（当时）市场领先的浏览器开始接受损坏的 HTML，其他浏览器不得不效仿，否则人们不会使用他们的产品（“浏览器 X 不会显示我最喜欢的网站，但它适用于浏览器 Y ，所以我将使用浏览器 Y。")

【解决方案2】：

“Fail Early”意味着如果出现问题，程序应该引发异常并停止工作。（在实用程序员的技巧列表中描述为Crash Early）

在我的生物信息学工作中，我倾向于使用“早期失败”的方法，因为我最关心的是确保正确性。相比之下，Rails 允许您隐藏故障。例如，Rails 的try 允许您在对象上调用某些东西，如果该对象是nil，它不会引发异常。我想这是因为对于网站，确保程序持续运行比正确性更重要。

【讨论】：

呃。这是你设置的吗？人们可以回答他们自己的问题，但你回答得相当完整，在你提出问题后仅仅 5 分钟，这让我觉得你在提出问题之前就已经知道答案了
@michael mrozek：公平地说，这不是他最初问题的完整答案。但作为问题的编辑，它比答案更可疑
我特别说“人们可以自己回答问题”，但我认为 FAQ 条目主要是为那些提出问题、搜索一段时间、找到答案并然后将其发布在他们自己的问题上，因为其他人都不知道。根据您回答的速度，您似乎发布了已经知道答案的问题，这有点愚蠢；你还不如刚刚写了博客。我可以整天坐在这里发布我已经知道答案的问题，并立即发布这些答案
@Michael Andrew 正在为 SO 添加价值并在这里分享他的工作，我对此没有任何错误或愚蠢。是的，您甚至可以将 SO 用作博客，甚至鼓励这样做。见meta.stackexchange.com/questions/17463/… 和meta.stackexchange.com/questions/2706/…
@Pas 我的意思是“发疯”，通俗地说是“随心所欲地这样做”，而不是“我觉得你这样做很疯狂”

【解决方案3】：

及早失败体现了这样一种理念，即在构建软件时越早失败或测试失败或发现错误就越容易纠正（而且成本也更低）。它也适用于您的商业模式。最好尽早发现（例如测试版）而不是在发布后发现。

【讨论】：

不，尽管您说的是正确的观点，但它与“早期失败”一词无关。安德鲁·格林有正确的解释（对他自己的问题同样如此！。
@NomeN：“热情的程序员”建议“早早失败”也应适用于业务：如果出现问题，请告诉其他人，不要掩盖。
再一次，这是正确的答案，它是在编程语言发展到在语言级别提供结构化异常之前几十年发现的。（此外，这个正确答案比另一个正确答案晚了 2 分钟发布，这个正确答案被错误地断言为“再次，不是正确答案。）
确实如此。如果一个项目或业务必须失败，最好早点失败（你会节省一些钱）。

【解决方案4】：

我曾经有一个初级 oracle 程序员为我工作，他在他的所有代码周围放置了一个“忽略一切”异常块，因此从未出现过错误。这最初使他的代码看起来令人印象深刻，但是： A) Bug 需要更长的时间才能找到；和 B) 在那之后，我对他的能力失去了所有（嗯，我 80% 的）信心。

我从那以后告诉人们这是一件非常糟糕的事情，因为它隐藏了错误。

不要将此与能够处理低质量输入的代码模块混淆（例如 HTML，它在浏览器中也不是有效的 XHTML）——这些根本不需要导致失败。更有可能的是，它们确实在多年前导致了故障，但解决它的方法是让系统对如何恢复做出合理的假设。

【讨论】：

【解决方案5】：

意思是：“尽早发现错误”。如果可能的话，你想知道他们一到那里就知道他们在那里=）。

越早发现错误，移除它的成本就越低。如果您能在编写错误行的时候就知道错误，那就太棒了。您将确切地知道自己打算做什么，并且最有能力快速消除该错误。

另一方面，如果您在一个月后或在它发布后才发现该错误，则损失要大得多。用户已经不得不处理它，你不会记得你的想法那么好（或者你甚至可能不再为公司工作，所以需要有人找出你的想法）。

【讨论】：

再次，不是正确的答案。你和史蒂夫罗比拉德的观点基本相同，我担心同样的错误。尽早失败是您应该在运行时处理异常！
@NomeN：公平地说，Samuel 描述的是“为什么”，而不是“如何”。
这是正确的答案，它在编程语言发展到在语言级别提供结构化异常之前的几十年就被发现了。