在 Java 中，異常處理是個很麻煩的事情。初學者覺得它很難理解，甚至是經驗豐富的開發者也要花費很長時間決定異常是要處理掉和丟擲。

所以很多開發團隊約定一些原則處理異常。如果你是一個團隊的新成員，你可能會很驚訝，因為他們約定的規則可能和你以前使用的規則不一樣。

不過，有很多最佳實踐的規則，被大部分團隊接受。這裡有 9 大重要的約定，幫助你學習或者改進異常處理。

1、在 Finally 清理資源或者使用 Try-With-Resource 特性

大部分情況下，在 try 程式碼塊中使用資源後需要關閉資源，例如 InputStream 。在這些情況下，一種常見的失誤就是在 try 程式碼塊的最後關閉資源。

問題就是，只有沒有異常丟擲的時候，這段程式碼才可以正常工作。try 程式碼塊內程式碼會正常執行，並且資源可以正常關閉。但是，使用 try 程式碼塊是有原因的，一般呼叫一個或多個可能丟擲異常的方法，而且，你自己也可能會丟擲一個異常，這意味著程式碼可能不會執行到 try 程式碼塊的最後部分。結果就是，你並沒有關閉資源。

所以，你應該把清理工作的程式碼放到 finally 裡去，或者使用 try-with-resource 特性。

使用 Finally 程式碼塊

與前面幾行 try 程式碼塊不同，finally 程式碼塊總是會被執行。不管 try 程式碼塊成功執行之後還是你在 catch 程式碼塊中處理完異常後都會執行。因此，你可以確保你清理了所有開啟的資源。

Java 7 的 Try-With-Resource 語法

另一個可選的方案是 try-with-resource 語法，我在介紹 Java 的異常處理裡更詳細的介紹了它。

如果你的資源實現了 AutoCloseable 介面，你可以使用這個語法。大多數的 Java 標準資源都繼承了這個介面。當你在 try 子句中開啟資源，資源會在 try 程式碼塊執行後或異常處理後自動關閉。

2、優先明確異常

你丟擲的異常越明確越好，永遠記住，你的同事或者幾個月之後的你，將會呼叫你的方法並且處理異常。

因此需要保證提供給他們儘可能多的資訊。這樣你的 API 更容易被理解。你的方法的呼叫者能夠更好的處理異常並且避免額外的檢查。

因此，總是嘗試尋找最適合你的異常事件的類，例如，丟擲一個 NumberFormatException 來替換一個 IllegalArgumentException 。避免丟擲一個不明確的異常。

3、記錄指定的異常

每當你在方法簽名中指定異常，你也應該在 Javadoc 中記錄它。 這與上一個最佳實踐具有相同的目標：儘可能多地向呼叫者提供資訊，以便避免或處理異常。

因此，請確保向 Javadoc 新增 @throws 宣告並描述可能導致異常的情況。

4、使用描述性訊息丟擲異常

這個最佳實踐背後的想法與前兩個類似。但這一次，你不會將資訊提供給方法的呼叫者。每個必須瞭解在日誌檔案或監視工具中報告異常情況時發生了什麼情況的人都可以讀取異常訊息。

因此，應該儘可能精確地描述問題，並提供最相關的資訊來了解異常事件。

不要誤會我的意思，你不用去寫一段文字。但你也應該在1-2個短句中解釋異常的原因。這有助於你的運營團隊瞭解問題的嚴重性，並且還可以讓你更輕鬆地分析任何服務突發事件。

如果丟擲一個特定的異常，它的類名很可能已經描述了這種錯誤。所以，你不需要提供很多額外的資訊。一個很好的例子是 NumberFormatException 。當你以錯誤的格式提供 String 時，它將被 java.lang.Long 類的建構函式丟擲。

NumberFormatException 類的名稱已經告訴你這種問題。它的訊息表示只需要提供導致問題的輸入字串。如果異常類的名稱不具有表達性，則需要在訊息中提供所需的資訊。

17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"

5、優先捕獲最具體的異常

大多數 IDE 都可以幫助你實現這個最佳實踐。當你嘗試首先捕獲較不具體的異常時，它們會報告無法訪問的程式碼塊。

但問題在於，只有匹配異常的第一個 catch 塊會被執行。 因此，如果首先捕獲 IllegalArgumentException ，則永遠不會到達應該處理更具體的 NumberFormatException 的 catch 塊，因為它是 IllegalArgumentException 的子類。

總是優先捕獲最具體的異常類，並將不太具體的 catch 塊新增到列表的末尾。

你可以在下面的程式碼片斷中看到這樣一個 try-catch 語句的例子。 第一個 catch 塊處理所有 NumberFormatException 異常，第二個處理所有非 NumberFormatException 異常的 IllegalArgumentException 異常。

6、不要捕獲 Throwable 類

Throwable 是所有異常和錯誤的超類。你可以在 catch 子句中使用它，但是你永遠不應該這樣做！

如果在 catch 子句中使用 Throwable ，它不僅會捕獲所有異常，也將捕獲所有的錯誤。JVM 丟擲錯誤，指出不應該由應用程式處理的嚴重問題。 典型的例子是 OutOfMemoryError 或者 StackOverflowError 。 兩者都是由應用程式控制之外的情況引起的，無法處理。

所以，最好不要捕獲 Throwable ，除非你確定自己處於一種特殊的情況下能夠處理錯誤。

7、不要忽略異常

你曾經有去分析過一個只執行了你用例的第一部分的 bug 報告嗎？

這通常是由於一個被忽略的異常造成的。開發者可能會非常肯定，它永遠不會被丟擲，並新增一個 catch 塊，不做處理或不記錄它。而當你發現這個塊時，你很可能甚至會發現其中有一個“這永遠不會發生”的註釋。

那麼，你可能正在分析一個不可能發生的問題。

所以，請不要忽略任何一個異常。 你不知道程式碼將來如何改變。有人可能會在沒有意識到會造成問題的情況下，刪除阻止異常事件的驗證。或者是丟擲異常的程式碼被改變，現在丟擲同一個類的多個異常，而呼叫的程式碼並不能阻止所有異常。

你至少應該寫一條日誌資訊，告訴大家這個不可思議的事發生了，而且有人需要檢查它。

原文出處： oschina

覺得本文對你有幫助？請分享給更多人。