圍繞RuntimeException或Error設計一個Application Exception層次結構會更好嗎？

Question

可能重複：
Unchecked exceptions in Java: Inherit from Error or RuntimeException?

在我們的應用程序是如何做錯誤處理，我們一直在穩步從檢查ExceptionHierarchy移動尋找（如異常 - > ApplicationException的 - > SomethingSpecificBadHappenedException），因爲在很多情況下，我們有很多長的調用鏈，它們只是傳遞了ApplicationException，並且它增加了很少的價值，但卻讓我們的API變得混亂（我們越來越同意Effective Exceptions。

在重新設計我們的錯誤處理周圍unchecked異常，有「故障屏障」的做法一致，我們最初開始與一個RuntimeException基礎層次，類似於Spring Data Access layer

的例子我們已經開始懷疑工作如果它會更清楚，讓他們從錯誤下降，尤其是迴避的事實，那就讓我們做這樣的事情一：我們在多個點的應用程序中

} catch (Exception e) {

，但隨後區分：

} catch (Throwable t) {或} catch (Error err) {

這感覺乾淨，但我想不出這之後的API主要的例子。我正在尋找來自最佳通用API的示例，說明哪裏可以根據我們的異常/錯誤層次結構，或者關於樣式或功能差異的評論，這些差異應該優先於另一個根。

Answer 1

除了其他的答案：你不應該捕捉錯誤或Throwable沒有重新投入「正常」的程序邏輯。我能想到的捕捉Error的子類的主要原因是：你正在使用你自己的類加載系統，並希望隔離損壞的插件。

爲的ThreadDeath的JavaDoc的說：

應用程序應抓住這一類的實例只有當它必須被異步終止後清理。如果ThreadDeath被一個方法捕獲，重新拋出它是非常重要的，以便線程真正死亡。

Answer 2

規則是，不要創建從Error後裔的應用程序例外。 Error層次結構旨在僅用於由JVM和核心庫報告的不可恢復錯誤。

我知道沒有主要的API違反這條規則。

Answer 3

您想擴展RuntimeException。

雖然... 這聽起來像是真正的問題是，你的組織認爲最好只是拋出ApplicationException，而不是拋出具體的，有意義的，有據可查的例外。

從你所引用的文獻：

應急
預期的條件下，要求從可以在方法的預期目的來表示的方法替代響應。該方法的調用者期望這些類型的條件並且具有應對它們的策略。

故障
一個未經計劃的條件，其防止方法從實現不能在不參考該方法的內部實現來描述其預期的目的。

像「一切都未經檢查」這樣的單一方法與「檢查一切」（在我看來，更糟糕）一樣糟糕。應用Java設置的相同約定：
如果條件是編程錯誤，那麼它是RuntimeException。
如果條件是呼叫者期望並且能夠處理的情況，請使用Exception。
如果條件是系統錯誤（如資源不可用），則阻止任何有意義的操作繼續進行，請使用Error（但這非常罕見）。