故障快速和故障安全異常處理原則是否不兼容？

Question

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

乍一看，我認爲快速失敗意味着我們希望在發生意外事件時使系統明顯失效。 我的意思是，如果工廠無法創建對象的實例，對於快速失敗原則，我們實際上不希望工廠返回null或空對象或部分初始化的對象，而這些對象偶然可能會應用程序正確使用 - >大多數情況下，我們會有意想不到的行爲，或者在另一個級別引發意外的異常，這些異常不會讓我們知道真正的問題在工廠。 這是什麼原理的意思？

故障安全原理對我來說很難理解。 Java中最常見的例子是集合，它們的迭代器和併發訪問。 據說一個允許在迭代列表的同時修改列表的集合/迭代器被稱爲fail-safe。通常通過最終迭代初始列表的副本來完成。 但是在這個例子中，我並不真正瞭解系統在哪裏出現故障......因此，雖然它是無故障的......故障在哪裏？我們只是遍歷一個拷貝，因此，根據我們的需要...... 我沒有看到任何匹配故障安全的維基定義...

因此，在這樣的類似文章： 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 似乎多了很多與故障安全原則的初始定義有關。 我認爲失效保險是當系統失敗時，我們必須確保失敗處理程序不會失敗，或者如果確實如此，請確保處理程序失敗時不會隱藏真正的初始問題。在給定的示例中，處理程序就在最初的失敗代碼附近，但情況並非總是如此。故障安全的手段對我來說更是這樣，我們正確處理可能發生的是，在故障處理程序或類似的東西...

因此對我來說這2條原則似乎沒有不兼容的錯誤。 你覺得呢？ 系統不能快速安全失靈&安全嗎？

Answer 1

這是更好地避免放在第一位故障（故障安全），但如果這是不可能的，這是最好的快速失敗（儘可能快失敗越好）。

這兩者不是對立的，而是互補的。

至於你說的 - 我喜歡我的代碼是作爲故障安全越好，但如果它不是，我希望它快速失敗。

Answer 2

安全失敗並不意味着某件事情不會失敗 - 這意味着當它失敗時，它會以安全的方式失敗。不可能失敗的東西是失敗證明 - 這是可能的。

一個失敗的，如果電纜斷裂現址安全電梯擁堵。騎手不方便卡住，但方便不死。

考慮一個迭代器的例子。這個理論認爲，最好立即向客戶代碼發出信號，說明有什麼不對勁，而不是盲目地回覆可能導致更嚴重問題的有效答案。它的客戶代碼具有安全意識，它有機會立即進行干預和恢復。所以在這種情況下，安全失效和失敗很快是兼容的，後者是實現前者的策略。

另一方面，考慮一個網絡瀏覽器在一個不熟悉電腦的人手中。他們正試圖看看他們的電影什麼時候開始。假設（天堂禁止）頁面上的HTML格式不正確。如果渲染器快速失敗，則可能會決定放棄渲染用戶想要查看的信息，因爲之前的<HR>標籤拼寫爲<H>。在這種情況下，最好只是錯誤地使頁面儘可能最好。這個錯誤可能是微不足道的，從來沒有發現過，或者很久以後就會被發現，因爲有人最終發現這個頁面看起來不太正確。所以這裏是一個例子，其中快速失敗不是一個好的策略安全失效。

如果這個網頁是我的網上銀行應用程序，那麼我肯定會希望它在爆發時（如果有一個回滾，當然會）爆炸，如果有絲毫出錯的話。那麼快速失敗再次成爲失敗安全的首選策略。

我的觀點是，故障安全本身就是一個概念，那快速失敗可能會或可能不會是一個特別的技術，有助於故障安全。