快速故障和故障安全异常处理原则不兼容吗？

Question

我想更好地了解什么是快速故障和故障安全。

乍一看，fail-fast 意味着我们希望在发生任何意外情况时让系统明显失败。 我的意思是，例如，如果工厂无法创建对象的实例，出于快速失败的原则，我们真的不希望工厂返回 null、空对象或部分初始化的对象，这些对象可能偶然被使用由应用程序正确 -> 大多数时候我们会遇到意外行为，或者在另一个级别引发意外异常，这不允许我们知道真正的问题在工厂中。 这个原理是什么意思？

故障安全原则对我来说很难理解。 Java 中最常见的例子是关于集合、它们的迭代器和并发访问。 据说允许在迭代列表时修改列表的集合/迭代器称为故障安全。它通常通过最终迭代初始列表的副本来完成。 但是在这个例子中，我真的不明白系统在哪里失败......因此虽然它是故障安全的......失败在哪里？我们只是迭代一个副本或不迭代，这取决于我们的需要...... 我没有看到任何与故障安全的 wiki 定义相匹配的内容...

因此在这样的文章中： http://www.certpal.com/blogs/2009/09/iterators-fail-fast-vs-fail-safe/ 他们将故障快速与故障安全相反......我只是不明白为什么我们将这个迭代称为故障安全......

我在这里找到了另一个例子： http://tutorials.jenkov.com/java-exception-handling/fail-safe-exception-handling.html 它似乎与故障安全原则的初始定义更相关。 我对故障安全的看法是，当系统发生故障时，我们必须确保故障处理程序不会失败，或者，如果确实如此，请确保真正的初始问题不会被处理程序的失败所掩盖。在给定的示例中，处理程序就在初始失败代码附近，但并非总是如此。故障安全对我来说意味着更多的东西，比如我们正确处理故障处理程序中可能发生的错误或类似的东西......

因此对我来说，这两条原则似乎并不矛盾。 你怎么看？ 系统不能快速安全地失败吗？？？

Answer 1

最好一开始就避免失败（fail safe），但如果这不可能，最好快速失败（尽可能快地失败）。

两者不是对立的，而是互补的。

正如你所说 - 我希望我的代码尽可能地安全，但如果不是，我希望它能够快速失败。

Answer 2

fail safe 并不意味着某事不会失败——它意味着当它失败时，它会以一种安全的方式失败。不能失败的东西是失败证明——这是可能的。

如果电缆断裂，故障安全电梯会在其当前位置卡住。骑手被卡住很不方便，但很方便没有死。

考虑一个迭代器的例子。理论上，最好立即向客户端代码发出信号，指出有问题，而不是盲目地返回一个看起来有效的答案，这可能会导致更严重的问题。如果客户端代码具有安全意识，它就有机会立即进行干预和恢复。所以在这种情况下，fail safe 和 fail fast 是兼容的，后者是实现前者的策略。

另一方面，考虑一个不熟悉计算机的人手中的网络浏览器。他们正试图看看他们的电影什么时候开始。假设（天堂禁止）页面上的 HTML 格式不正确。如果渲染器快速失败，它可能会决定放弃渲染用户想要查看的信息，因为前面的<HR> 标记拼写为<H>。在这种情况下，最好只是犯错，尽可能地渲染页面。该错误可能是微不足道的并且永远不会被捕获，或者它可能会在很久很久之后才被捕获，因为有人最终注意到页面看起来不太正确。所以这里有一个例子，fail fast 对于fail safe来说并不是一个好的策略。

如果该网页是我的网上银行应用程序，我肯定希望它在出现最轻微的问题时轰然倒塌（当然是回滚）。那么fail fast再次成为fail safe的首选策略。

我的观点是 fail safe 本身就是一个概念，fail fast 可能是也可能不是有助于故障安全的特定技术。