Java異常處理的良好做法

Question

我有一些關於處理Java異常的問題。我讀了一些，並得到了一些矛盾的指導方針。

Best Practices for Exception Handling

讓我們通過所提到的文章：

它指出一個一般應避免使用checked異常如果「客戶端代碼無法做任何事情」。但是，這究竟意味着什麼？在GUI中顯示錯誤消息是否有足夠的理由冒泡檢查異常？但它會強制GUI程序員記住捕獲RuntimeExceptions及其後代以顯示潛在的錯誤信息。

本文中提出的第二種觀點是，除非我想在其中實施一些關聯字段/方法，否則應該避開創建自己的異常類。 我通常不同意這一點，今天我的做法恰恰相反：我在自己的異常結構中封裝了異常，以反射由我編寫的類實現的目標，即使它們只是在不添加任何新方法的情況下擴展Exception。我認爲在拋出更高層次時更靈活地處理它們對於使用這些類的程序員來說通常會更清晰和易於理解。

我在這篇文章中拋出RuntimeException的文章中提出了今天的'新方法'，然後我讓Sonar對它進行分析。令我更困惑的是，Sonar將我的RuntimeExceptions標記爲主要錯誤，並帶有一條消息，如「避免拋出根類型異常，將wrap'em放入自己的類型中」。

所以它看起來很有爭議，你怎麼看？

我今天也從一位技術領導聽到，只是包裝異常是不好的，'因爲這對於JVM來說是非常昂貴的操作。對我來說，另一方面拋出的SQLExceptions或IOExceptions在任何地方看起來都有點破解封裝..

那麼你對我在這裏提出的問題的一般態度是什麼？

1. 當包在我自己的類型的例外，當我不應該這樣做呢？

2. 哪裏是那點「客戶端不能做的事，拋出 運行時異常？'

3. 性能問題呢？

Answer 1

它看起來像你的技術，鉛，經常已經逃到了開發商的角色，因爲他不擅長。

我的建議是：

• 喜歡運行時異常過度檢查異常，特別是如果你不是你的API的唯一客戶。使用檢查的異常會強制每個客戶端處理異常，即使它不能對其執行任何操作。如果這真的是你想做的事情（即強制調用者處理它），那麼檢查的異常就是你想要的。
• 如果客戶端發生異常時唯一可以做的事情是顯示或多或少的泛型錯誤消息，例如「oops，發生了什麼壞事，請重試或返回歡迎頁面」，然後肯定使用運行時異常。大多數表示框架提供了一種使用通用錯誤處理程序的方法。
• 絕對使用鏈接到抽象層的異常。從高級服務中拋出SQLException是不夠的。使用現有的異常類型（如IllegalArgumentException來表示非法參數）。否則，將低級異常包裝到更高級別的適當異常類型中。什麼是昂貴的是拋出一個例外。它是否包裹另一個並不重要。無論如何，它應該只發生異常。