關(guān)于JAVA異常處理的20個最佳實踐

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

異常類型

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

用戶自定義異常

任何時候，當用戶覺得他出于某種原因想要使用自己的特定于應(yīng)用程序的異常時，他可以創(chuàng)建一個新的類來適當?shù)臄U展超類（主要是它的Exception.java）并開始在適當?shù)牡胤绞褂盟?這些用戶定義的異常可以以兩種方式使用：
1) 當應(yīng)用程序出現(xiàn)問題時，直接拋出自定義異常

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); }

包裝異常可以通過添加自己的消息/上下文信息來為用戶提供額外信息，同時仍保留原始異常的堆棧跟蹤和消息。 它還允許你隱藏代碼的實現(xiàn)細節(jié)，這是封裝異常的最重要原因。

現(xiàn)在讓我們開始探索遵循行業(yè)聰明的異常處理的最佳實踐。

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

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

catch (NoSuchMethodException e) {return null; }

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

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

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

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

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

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

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

4) 永遠不要捕獲Throwable類

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

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

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

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

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

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

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

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

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

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

只要cleanUp()永遠不會拋出任何異常，上面的代碼沒有問題。 但是如果someMethod()拋出一個異常，并且在finally塊中，cleanUp()也拋出另一個異常，那么程序只會把第二個異常拋出來，原來的第一個異常（正確的原因）將永遠丟失。 如果你在finally塊中調(diào)用的代碼可能會引發(fā)異常，請確保你要么處理它，要么將其記錄下來。 永遠不要讓它從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中處理的異常，但是仍然希望在發(fā)生異常時進行一些清理，然后在finally塊中進行清理。 不要使用catch塊。

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

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

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

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

如果你正在使用數(shù)據(jù)庫連接或網(wǎng)絡(luò)連接等資源，請確保清除它們。 如果你正在調(diào)用的API僅使用非檢查性異常，則仍應(yīng)使用try-finally塊來清理資源。 在try模塊里面訪問資源，在finally里面最后關(guān)閉資源。 即使在訪問資源時發(fā)生任何異常，資源也會優(yōu)雅地關(guān)閉。

13) 只從方法中拋出相關(guān)異常

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

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

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

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

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

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

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

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

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

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

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

不要這樣做。

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

像這樣做：

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

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

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

18) 終止掉被中斷線程

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

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

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

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

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

例如，下面的代碼嘗試關(guān)閉數(shù)據(jù)庫連接。

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

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。