我想更好地了解什么是快速失败和故障安全。
乍一看，我认为快速失败意味着我们希望在任何意外情况发生时让系统明显失败。 我的意思是例如，如果工厂不能创建对象的实例，对于故障快速原则，我们真的不希望工厂返回null，或者空对象，或者部分初始化的对象，偶然可以使用正确的应用程序 - ＆gt;大部分时间我们都会遇到意想不到的行为，或者在另一个层面上提出的意外异常，这个异常不允许我们知道真实的事情是在工厂里。 这个原则意味着什么？
对我来说很难理解失败安全原则。 Java中最常见的例子是关于集合，它们的迭代器和并发访问。 据说，允许在迭代时修改列表的集合/迭代器称为故障安全。它通常通过最终迭代初始列表的副本来完成。 但是在这个例子中，我并不真正了解系统失败的地方......因此，虽然它是故障安全的......失败在哪里？我们只是根据我们的需要迭代一个副本... 我没有看到与故障安全的维基定义有任何匹配...
因此在这样的文章中： 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 它似乎与故障安全原则的初始定义有很多关系。 我认为故障安全的是，当系统出现故障时，我们必须确保故障处理程序不会失败，或者如果确实如此，则确保故障处理程序的故障不会隐藏真正的初始问题。在给定的例子中，处理程序就在初始故障代码附近，但情况并非总是如此。故障安全对我来说意味着我们正确处理故障处理程序中可能发生的错误或类似的事情......
因此对我来说，这两条原则似乎并不相容。 你怎么看？ 一个系统不能快速失败＆amp;安全地???
答案 0 :(得分：8)
最好首先避免失败（故障安全），但如果不可能，最好快速失败（尽快失败）。
这两者不是对立的，而是互补的。
正如你所说 - 我喜欢我的代码尽可能地保证安全，但是如果不安全，我希望它快速失败。
答案 1 :(得分：4)
故障安全并不意味着某些东西不会失败 - 这意味着当它失败时，它会以安全的方式失败。不能失败的是失败证明 - 这是可能的。
如果电缆断裂，则故障安全电梯会在其当前位置卡住。车手不方便卡住，但不方便死。
考虑一个迭代器的例子。理论上说，最好立即向客户端代码发出信号，告诉他们有什么不妥，而不是盲目地回复可能导致更严重问题的有效回答。它的客户端代码具有安全意识，它有机会立即进行干预和恢复。所以在这种情况下，故障安全和快速失败是兼容的，后者是实现前者的策略。
另一方面，考虑一个不熟悉计算机的人手中的网络浏览器。他们试图看看他们的电影什么时候开始。让我们说（天堂禁止）页面上的HTML格式不正确。如果渲染器快速失败，它可能会决定放弃渲染用户想要查看的信息，因为前面的<HR>标记拼写为<H>。在这种情况下，最好只是错误，使页面尽可能最好。这个错误可能是微不足道的，从来没有被发现，或者它可能被捕获很多，很久以后，有人终于注意到页面看起来不太正确。所以这里有一个例子，其中快速失败不是故障安全的好策略。
如果网页是我的网上银行应用程序，我肯定希望它能够在最轻微的问题出现时大发雷霆（当然还有回滚）。因此，失败快速再次成为故障安全的首选策略。
我的观点是故障安全本身就是一个概念，快速失败可能是也可能不是导致故障安全的特定技术。