Java程式設計中關於異常處理的10個要點
阿新 • • 發佈：2018-11-11
Java程式設計中關於異常處理的10個要點
- 如果是可恢復錯誤,使用檢查型異常;如果是程式設計錯誤,使用非檢查型異常。許多Java程式設計人員都很苦惱,到底是該選擇檢查型異常還是非檢查型異常。檢查型異常是一種從語言到強制你編寫程式碼的一種方式,可以保證你對錯誤條件提供異常處理程式碼,但同時也會引入大量雜亂的程式碼導致其不可讀。如果你有恢復策略的話,這樣做看起來似乎也可以。
- 在finally程式塊中關閉或者釋放資源Java程式設計師對此都有所瞭解,在處理網路和IO類的時候,相當於一個標準。在finally塊中關閉資源, 在正常和異常執行的情況下,保證之前和稀缺資源的合
理釋放,這由finally塊保證。從Java7開始,該語言有了一項更好的功能:資源管理自動化或者ARM塊能實現這一功能。儘管如此,我們仍然要記住在finally塊中關閉資源,這是對於釋放像FileDescriptors這類,應用在socket和檔案程式設計的情況下的有限資源很重要的。 - 在堆疊跟蹤中包含引起異常的原因很多時候,當一個異常由另一個異常導致異常而被丟擲的時候,Java庫和開放原始碼會將一種異常包裝成另一種異常。這時,日誌記錄和列印根異常就變得非常重
要。Java異常類提供了 getCause()方法來檢索導致異常的原因,這些可以對異常根層次的原因提供更多的資訊。該Java實踐對程式碼的除錯或故障排除有很大的幫助。另外,如果你要把一個異常包裝成另一種異常,構造一個新異常就要傳遞源異常。 - 始終提供關於異常的有意義的完整資訊異常資訊非常重要,因為這是Java程式設計師最先看到的一個地方,在這裡會有非常精確並且真實的資訊,他們可以找到問題產生的根本原因。
- 避免過度使用檢查型異常 檢查型異常在強制執行方面有一定的優勢,但同時它也破壞了程式碼,通過掩蓋業務邏輯使程式碼可讀性降低。所以,Java程式設計師要注意,不能過度使用檢查型異常,你可以最大程度的減少這類情況,這樣你會得到更精準、簡潔的程式碼。
- 將檢查型異常轉為執行時異常這個像是Spring之類的多數框架中,用來限制使用檢查型異常的技術之一,大部分出自於JDBC的檢查型異常,都被包裝進 DataAccessException中,而(DataAccessException)異常是一種非檢查型異常。特定的異常限制到特定的模組,像
SQLException 放到DAO層,將執行時異常明確的說明然後拋到客戶層。 - 記住對效能而言,異常代價比較高異常代價比較高,還會讓你的程式碼執行變得緩慢。如果你有方法從ResultSet(結果集)中進行讀取,這時常會丟擲SQLException 異常而不會移到下一元素,這將會比不丟擲異常的正常程式碼執行速度慢很多。因此Java程式設計師要最大限度的減少不必要的異常捕捉和移動。如果你能使用boolean變數去表示執行結果,而不僅僅只是丟擲和捕捉異常,你就有可能得到更簡潔、更高效能的解決方案。
- 避免catch塊為空沒有什麼會比空的catch塊更糟糕的了,因為它不僅隱藏了錯誤和異常,還可能導致你的物件處於不可使用的狀態。空的catch塊沒有任何意義,如果你非常肯定異常不會繼續以任何方式影響物件狀態,在程式執行期間,用日誌記錄錯誤依然是最好的方法。
- 使用標準異常java程式設計師應該學會使用標準異常,而不是每次都建立自己的異常。對於維護性和一致性,不管是現在還是以後,都是最好的選擇。重用標準異常使程式碼更具可讀性,因為大部分Java開發人員對標準,像源自於JDK的RuntimeException 異常,IllegalStateException 異
常,IllegalArgumentException 異常或者NullPointerException異常,他們能一眼就知道每種異常的目的,而不是在程式碼裡查詢或者在文件裡查詢使用者定義的異常的目的。
10.記錄任何方法丟擲的異常Java提供了throw和throws關鍵字來丟擲異常,在javadoc中用@throw記錄任何方法可能會丟擲的異常。如果你編寫API或者公共介面,這就變得非常重要。任何方法丟擲的異常都有相應的文件記錄,這樣你就能下意識的提醒任何使用(該方法)的人。