關于JAVA異常處理的20個最佳實踐

在我們深入了解異常處理最佳實踐的深層概念之前，讓我們從一個最重要的概念開始，那就是理解在JAVA中有三種一般類型的可拋類: 檢查性異常(checked exceptions)、非檢查性異常(unchecked Exceptions) 和 錯誤(errors)。

異常類型

檢查性異常(checked exceptions) 是必須在在方法的throws子句中聲明的異常。它們擴展了異常，旨在成為一種“在你面前”的異常類型。JAVA希望你能夠處理它們，因為它們以某種方式依賴于程序之外的外部因素。檢查的異常表示在正常系統操作期間可能發生的預期問題。 當你嘗試通過網絡或文件系統使用外部系統時，通常會發生這些異常。 大多數情況下，對檢查性異常的正確響應應該是稍后重試，或者提示用戶修改其輸入。
非檢查性異常(unchecked Exceptions) 是不需要在throws子句中聲明的異常。 由于程序錯誤，JVM并不會強制你處理它們，因為它們大多數是在運行時生成的。 它們擴展了RuntimeException。 最常見的例子是NullPointerException [相當可怕..是不是？]。 未經檢查的異?？赡懿粦撝卦?#xff0c;正確的操作通常應該是什么都不做，并讓它從你的方法和執行堆棧中出來。 在高層次的執行中，應該記錄這種類型的異常。
錯誤(errors) 是嚴重的運行時環境問題，幾乎肯定無法恢復。 例如OutOfMemoryError，LinkageError和StackOverflowError, 它們通常會讓程序崩潰或程序的一部分。 只有良好的日志練習才能幫助你確定錯誤的確切原因。

用戶自定義異常

任何時候，當用戶覺得他出于某種原因想要使用自己的特定于應用程序的異常時，他可以創建一個新的類來適當的擴展超類（主要是它的Exception.java）并開始在適當的地方使用它。 這些用戶定義的異?？梢砸詢煞N方式使用：
1) 當應用程序出現問題時，直接拋出自定義異常

throw new DaoObjectNotFoundException("Couldn't find dao with id " + id);

2) 或者將自定義異常中的原始異常包裝并拋出

catch (NoSuchMethodException e) {throw new DaoObjectNotFoundException("Couldn't find dao with id " + id, e); }

包裝異?？梢酝ㄟ^添加自己的消息/上下文信息來為用戶提供額外信息，同時仍保留原始異常的堆棧跟蹤和消息。 它還允許你隱藏代碼的實現細節，這是封裝異常的最重要原因。

現在讓我們開始探索遵循行業聰明的異常處理的最佳實踐。

你必須考慮并遵循的最佳做法

1) 永遠不要吞下catch塊中的異常

catch (NoSuchMethodException e) {return null; }

2) 在你的方法里拋出定義具體的檢查性異常

public void foo() throws Exception { //錯誤方式 }

一定要避免出現上面的代碼示例。 它簡單地破壞了檢查性異常的整個目的。 聲明你的方法可能拋出的具體檢查性異常。 如果只有太多這樣的檢查性異常，你應該把它們包裝在你自己的異常中，并在異常消息中添加信息。 如果可能的話，你也可以考慮代碼重構。

public void foo() throws SpecificException1, SpecificException2 { //正確方式 }

3) 捕獲具體的子類而不是捕獲Exception類

try {someMethod(); } catch (Exception e) { //錯誤方式LOGGER.error("method has failed", e); }

捕獲異常的問題是，如果稍后調用的方法為其方法聲明添加了新的檢查性異常，則開發人員的意圖是應該處理具體的新異常。 如果你的代碼只是捕獲異常（或Throwable），你永遠不會知道這個變化，以及你的代碼現在是錯誤的，并且可能會在運行時的任何時候中斷。

4) 永遠不要捕獲Throwable類

這是一個更嚴重的麻煩。 因為java錯誤也是Throwable的子類。 錯誤是JVM本身無法處理的不可逆轉的條件。 對于某些JVM的實現，JVM可能實際上甚至不會在錯誤上調用catch子句。

5) 始終正確包裝自定義異常中的異常，以便堆棧跟蹤不會丟失

catch (NoSuchMethodException e) {throw new MyServiceException("Some information: " + e.getMessage()); //錯誤方式 }

這破壞了原始異常的堆棧跟蹤，并且始終是錯誤的。 正確的做法是：

catch (NoSuchMethodException e) {throw new MyServiceException("Some information: " , e); //正確方式 }

6) 要么記錄異常要么拋出異常，但不要一起執行

catch (NoSuchMethodException e) { //錯誤方式 LOGGER.error("Some information", e);throw e; }

正如在上面的示例代碼中，記錄和拋出異常會在日志文件中產生多條日志消息，代碼中存在單個問題，并且讓嘗試挖掘日志的工程師生活得很糟糕。

7) finally塊中永遠不要拋出任何異常

try {someMethod(); //Throws exceptionOne } finally {cleanUp(); //如果finally還拋出異常，那么exceptionOne將永遠丟失 }

只要cleanUp()永遠不會拋出任何異常，上面的代碼沒有問題。 但是如果someMethod()拋出一個異常，并且在finally塊中，cleanUp()也拋出另一個異常，那么程序只會把第二個異常拋出來，原來的第一個異常（正確的原因）將永遠丟失。 如果你在finally塊中調用的代碼可能會引發異常，請確保你要么處理它，要么將其記錄下來。 永遠不要讓它從finally塊中拋出來。

8) 始終只捕獲實際可處理的異常

catch (NoSuchMethodException e) {throw e; //避免這種情況，因為它沒有任何幫助 }

這是最重要的概念。 不要為了捕捉異常而捕捉，只有在想要處理異常時才捕捉異常，或者希望在該異常中提供其他上下文信息。 如果你不能在catch塊中處理它，那么最好的建議就是不要只為了重新拋出它而捕獲它。

9) 不要使用printStackTrace()語句或類似的方法

完成代碼后，切勿忽略printStackTrace()。 你的同事可能會最終得到這些堆棧，并且對于如何處理它完全沒有任何知識，因為它不會附加任何上下文信息。

10) 如果你不打算處理異常，請使用finally塊而不是catch塊

try {someMethod(); //Method 2 } finally {cleanUp(); //do cleanup here }

這也是一個很好的做法。 如果在你的方法中你正在訪問Method 2，而Method 2拋出一些你不想在method 1中處理的異常，但是仍然希望在發生異常時進行一些清理，然后在finally塊中進行清理。 不要使用catch塊。

11) 記住“早throw晚catch”原則

這可能是關于異常處理最著名的原則。 它基本上說，你應該盡快拋出(throw)異常，并盡可能晚地捕獲(catch)它。 你應該等到你有足夠的信息來妥善處理它。

這個原則隱含地說，你將更有可能把它放在低級方法中，在那里你將檢查單個值是否為空或不適合。 而且你會讓異常堆棧跟蹤上升好幾個級別，直到達到足夠的抽象級別才能處理問題。

12) 清理總是在處理異常之后

如果你正在使用數據庫連接或網絡連接等資源，請確保清除它們。 如果你正在調用的API僅使用非檢查性異常，則仍應使用try-finally塊來清理資源。 在try模塊里面訪問資源，在finally里面最后關閉資源。 即使在訪問資源時發生任何異常，資源也會優雅地關閉。

13) 只從方法中拋出相關異常

相關性對于保持應用程序清潔非常重要。 一種嘗試讀取文件的方法; 如果拋出NullPointerException，那么它不會給用戶任何相關的信息。 相反，如果這種異常被包裹在自定義異常中，則會更好。 NoSuchFileFoundException則對該方法的用戶更有用。

14) 切勿在程序中使用流程控制異常

我們已經閱讀過很多次，但有時我們還是會在項目中看到開發人員嘗試為應用程序邏輯而使用異常的代碼。 永遠不要這樣做。 它使代碼很難閱讀，理解和丑陋。

15) 驗證用戶輸入以在請求處理的早期捕獲不利條件

始終要在非常早的階段驗證用戶輸入，甚至在達到實際controller之前。 它將幫助你把核心應用程序邏輯中的異常處理代碼量降到最低。 如果用戶輸入出現錯誤，它還可以幫助你使與應用程序保持一致。

例如：如果在用戶注冊應用程序中，你遵循以下邏輯：

1）驗證用戶
2）插入用戶
3）驗證地址
4）插入地址
5）如果出問題回滾一切

這是非常不正確的做法。 它會使數據庫在各種情況下處于不一致的狀態。 首先驗證所有內容，然后將用戶數據置于dao層并進行數據庫更新。 正確的做法是：

1）驗證用戶
2）驗證地址
3）插入用戶
4）插入地址
5）如果問題回滾一切

16) 一個異常只能包含在一個日志中

LOGGER.debug("Using cache sector A"); LOGGER.debug("Using retry sector B");

不要這樣做。

對多個LOGGER.debug()調用使用多行日志消息可能在你的測試用例中看起來不錯，但是當它在具有400個并行運行的線程的應用程序服務器的日志文件中顯示時，所有轉儲信息都是相同的日志文件，你的兩個日志消息最終可能會在日志文件中間隔1000行，即使它們出現在代碼的后續行中。

像這樣做：

LOGGER.debug("Using cache sector A, using retry sector B");

17) 將所有相關信息盡可能地傳遞給異常

有用且信息豐富的異常消息和堆棧跟蹤也非常重要。 如果你的日志不能確定任何事情（有效內容不全或很難確定問題原因），
那要日志有什么用？ 這類的日志只是你代碼中的裝飾品。

18) 終止掉被中斷線程

while (true) {try {Thread.sleep(100000);} catch (InterruptedException e) {} //別這樣做doSomethingCool(); }

InterruptedException是你的代碼的一個提示，它應該停止它正在做的事情。 線程中斷的一些常見用例是active事務超時或線程池關閉。 你的代碼應該盡最大努力完成它正在做的事情，并且完成當前的執行線程，而不是忽略InterruptedException。 所以要糾正上面的例子：

while (true) {try {Thread.sleep(100000);} catch (InterruptedException e) {break;} } doSomethingCool();

19) 使用模板方法重復try-catch

在你的代碼中有100個類似的catch塊是沒有用的。 它增加代碼的重復性而且沒有任何的幫助。 對這種情況要使用模板方法。

例如，下面的代碼嘗試關閉數據庫連接。

class DBUtil{public static void closeConnection(Connection conn){try{conn.close();} catch(Exception ex){//Log Exception - Cannot close connection}} }

這種類型的方法將在你的應用程序的成千上萬個地方使用。 不要把這塊代碼放的到處都是，而是定義頂層的方法，并在下層的任何地方使用它：

public void dataAccessCode() {Connection conn = null;try{conn = getConnection();....} finally{DBUtil.closeConnection(conn);} }

20) 在JavaDoc中記錄應用程序中的所有異常

把注釋(javadoc)運行時可能拋出的所有異常作為一種習慣。
也要盡可能包括可行的方案，用戶應該關注這些異常發生的情況。

這就是我現在所想的。 如果你發現任何遺漏或你與我的觀點不一致，請發表評論。 我會很樂意討論。

總結

以上是生活随笔為你收集整理的关于JAVA异常处理的20个最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。