Java異常處理的9個最佳實踐

時間 2020-01-05

標籤 java 異常處理最佳實踐欄目 Java 简体版

原文原文鏈接

不管你是新手仍是資深程序員，複習下異常處理的實踐老是一件好事，由於這能確保你與你的團隊在遇到問題時可以處理得了它。html

在 Java 中處理異常並非一件易事。新手以爲處理異常難以理解，甚至是資深開發者也會花上好幾個小時來討論是應該拋出拋異常仍是處理異常。java

這就是爲什麼大多數開發團隊都擁有一套本身的異常處理規範。若是你初進團隊，你也許會發現這些規範和你曾使用的規範截然不同。程序員

儘管如此，這裏仍是有一些被大多數團隊所遵循的最佳實踐準則。如下9個最重要的實踐方法能幫助你開始進行異常處理，或提升你的異常處理水平。api

一、在 Finally 中清理資源或使用 Try-With-Resource 語句

在實際開發中會常常遇到在 try 中使用資源的狀況，好比一個 InputStream ，在使用後你須要關閉它。在這種狀況下，一個常見的錯誤是在 try 的尾部關閉了資源。oracle

public void doNotCloseResourceInTry() {
    FileInputStream inputStream = null;
    try {
        File file = new File("./tmp.txt");
        inputStream = new FileInputStream(file);
        // use the inputStream to read a file
        // do NOT do this
        inputStream.close();
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    }
}

這種狀況的問題是，只要異常沒被拋出，程序就能很好地運行。全部在 try 中的代碼都將被正常執行，資源也會被關閉。app

可是，用 try 老是有緣由的。當你調用一個或多個可能會拋出異常的方法或本身主動拋出異常時，程序可能會沒法到達 try 的尾部。因而在最後，資源將不被關閉。框架

由於，你應該將全部清理資源的代碼放進 finally 中，或使用 try-with-resource 語句。ide

使用 Finally

與 try 相比，不管是 try 中的代碼被成功執行，仍是在 catch 中處理了一個異常後，Finally 中的代碼總會被執行。所以，你能夠確保全部已打開的資源都將被關閉。函數

public void closeResourceInFinally() {
    FileInputStream inputStream = null;
    try {
        File file = new File("./tmp.txt");
        inputStream = new FileInputStream(file);
        // use the inputStream to read a file
    } catch (FileNotFoundException e) {
        log.error(e);
    } finally {
        if (inputStream != null) {
            try {
                inputStream.close();
            } catch (IOException e) {
                log.error(e);
            }
        }
    }
}

Java 7 的 Try-With-Resource 語句

你還能夠選擇 try-with-resource 語句，在個人這篇Java 異常處理入門中有更爲詳細的介紹。this

若是你在資源中實現了 AutoCloseable 接口的話，就可使用 try-with-resource 語句了，這也是大多數 Java 標準資源的作法。若是你在 try-with-resource 中打開了一個資源，在 try 中的代碼被執行或異常處理後，這個資源將會被自動關閉。

public void automaticallyCloseResource() {
    File file = new File("./tmp.txt");
    try (FileInputStream inputStream = new FileInputStream(file);) {
        // use the inputStream to read a file
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    }
}

二、拋出更具體的異常

你拋出的異常越具體、越明確越好。時刻牢記這點，特別是若是有一位並不瞭解你代碼的同事，或幾個月後的你須要調用本身的方法並處理異常時。

所以，你須要確保提供儘量多的信息，這會使得你的 API 更易於理解。這樣，調用你方法的人能夠更好地處理異常，從而避免額外的諸如此類的檢查。

因此，應該找到與你的異常事件最符合的類，好比拋出一個 NumberFormatException 而不是 IllegalArgumentException (注：例如將參數轉換爲數值出錯時，應該拋出具體的 NumberFormatException ，而不是籠統的 IllegalArgumentException )。請避免拋出一個不具體的異常。

public void doNotDoThis() throws Exception {
    ...
}
public void doThis() throws NumberFormatException {
    ...
}

三、爲你的異常編寫文檔

當你在方法簽名中指定一個異常時，你也應該在 Javadoc 中記錄它。

因此，請確保在 Javadoc 中增長 @throws 聲明，並描述可能會致使異常的狀況。

/**
 * This method does something extremely useful ...
 *
 * @param input
 * @throws MyBusinessException if ... happens
 */
public void doSomething(String input) throws MyBusinessException {
    ...
}

四、將描述信息與異常一同拋出

這個方法背後的思想和前兩個是相似的。但這一次，你沒必要給你的方法調用者提供信息。對於任何遭遇異常錯誤並須要搞清楚錯誤緣由的人來講，異常信息老是在異常出現的同時，被記錄在了日誌中，或打印在了屏幕上。

所以，請儘量精確地描因此，最好不要在 catch 中使用 Throwable ，除非你能確保本身處於一些特定狀況下，好比你本身足以處理錯誤，又或被要求處理錯誤時。述異常事件，並提供最相關的信息以令其餘人可以理解發生了什麼異常時。

別誤會個人意思了。你不必去寫上一大段的文字，但你應該用一兩句簡短的話來解釋一下異常發生的緣由。這能讓你的開發團隊明白問題的嚴重性，也能讓你更容易地分析服務事故。

若是你拋出了一個特定的異常，它的類名極可能就已經描述了這是什麼類型的錯誤了。因此，你不須要提供不少額外的描述信息。一個很好的例子是，當你提供了一個錯誤格式的 String 類型參數時，java.lang.Long 構造函數就會拋出 NumberFormatException 。

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

五、優先捕獲具體的異常

大多數 IDE 都能幫你作到這點。當你嘗試優先捕獲不那麼具體的異常時， IDE 會報告給你這是一個不能到達的代碼塊。

這個問題的緣由是隻有第一個匹配到異常的 catch 塊纔會被執行。因此，若是你先 catch 了一個 IllegalArgumentException ，你將永遠沒法到達處理更具體異常 NumberFormatException 的 catch 塊中，由於 NumberFormatException 是 IllegalArgumentException 的子類。

因此，請優先捕獲更具體的異常，並把不那麼具體的 catch 塊放在後面。

在下面你能夠看到這樣的一個 try-catch 語句示例。第一個 catch 處理全部的 NumberFormatExceptions 異常，第二個 catch 處理 NumberFormatException 異常之外的 illegalargumentexception 異常。

public void catchMostSpecificExceptionFirst() {
    try {
        doSomething("A message");
    } catch (NumberFormatException e) {
        log.error(e);
    } catch (IllegalArgumentException e) {
        log.error(e)
    }
}

六、不要捕獲 Throwable

Throwable 是全部 exceptions 和 errors 的父類。雖然你能夠在 catch 子句中使用它，但你應該永遠別這樣作！

若是你在 catch 子句中使用了 Throwable ，它將不只捕獲全部異常，還會捕獲全部錯誤。這些錯誤是由 JVM 拋出的，用來代表不打算由應用處理的嚴重錯誤。 OutOfMemoryError 和 StackOverflowError 就是典型的例子，這兩種狀況都是由一些超出應用控制範圍的狀況致使的，沒法處理。

因此，最好不要在 catch 中使用 Throwable ，除非你能確保本身處於一些特定狀況下，好比你本身足以處理錯誤，又或被要求處理錯誤。

public void doNotCatchThrowable() {
    try {
        // do something
    } catch (Throwable t) {
        // don't do this!
    }
}

七、不要忽略異常

你分析過只有用例的第一部分代碼被執行的 bug 報告嗎？

這一般是因爲忽略異常而致使的。開發者可能十分肯定這個異常不會被拋出，而後添加了一個沒法處理或沒法記錄這個異常的 catch 。當你找到這個 catch 時，你極可能會發現這麼一句著名的註釋：「This will never happen」。

public void doNotIgnoreExceptions() {
    try {
        // do something
    } catch (NumberFormatException e) {
        // this will never happen
    }
}

沒錯，你可能就是在分析一個永遠也不會發生的問題。

因此，請你務必不要忽略異常。你不知道代碼在未來會經歷怎樣的改動。有些人可能會誤刪異常事件的驗證，而徹底沒意識到這會產出問題。或者拋出異常的代碼被修改了，相同的類被拋出了多個異常，而調用它們的代碼並不能阻止這些異常發生。

你至少應該把日誌信息打印出來，告訴那些無心識下錯誤操做的人須要檢查這裏。

public void logAnException() {
    try {
        // do something
    } catch (NumberFormatException e) {
        log.error("This should never happen: " + e);
    }
}

八、不要同時打印並拋出異常

這多是本文中最常被忽略的一條實踐準則了。你能夠在許多代碼片斷甚至庫中發現這個問題，異常被捕獲，打印，再被從新拋出。

try {
    new Long("xyz");
} catch (NumberFormatException e) {
    log.error(e);
    throw e;
}

這樣也許會很直觀地看到被打印的異常，異常再被從新拋出，調用者也能很好地處理它。但這樣會使多個錯誤信息被同個異常給打印出來。

17:44:28,945 ERROR TestExceptionHandling:65 - java.lang.NumberFormatException: For input string: "xyz"
Exception in thread "main" java.lang.NumberFormatException: For input string: "xyz"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:589)
at java.lang.Long.(Long.java:965)
at com.stackify.example.TestExceptionHandling.logAndThrowException(TestExceptionHandling.java:63)
at com.stackify.example.TestExceptionHandling.main(TestExceptionHandling.java:58)

額外的信息並不能提供更多的錯誤細節。如第4條準則中所述，異常信息應該準確描述異常事件。 Stack Trace (堆棧追蹤)會告訴你異常在哪一個類、哪一個方法、哪一個行中被拋出。

若是你須要添加額外的信息，你應該將異常捕獲幷包裝在自定義的的異常中，但要確保遵循下面的第9條實踐準則。

public void wrapException(String input) throws MyBusinessException {
    try {
        // do something
    } catch (NumberFormatException e) {
        throw new MyBusinessException("A message that describes the error.", e);
    }
}

因此，只有在你想要處理一個異常的時候纔去捕獲它。不然，在方法簽名處指明這個異常讓調用者關注就行了。

九、包裝異常但不要丟棄原始異常

有時候將異常包裝成一個自定義異常會比捕捉一個標準異常要更好。一個典型的例子是應用或框架的特定業務異常。這容許你添加額外的信息，也能爲你的異常類實現一個特定的處理方法。

當你這麼作的時候，必定要確保原始的異常設爲 cause 。 Exception 類提供了一系列的特定構造方法，這些方法能夠接受 Throwable 做爲參數(注：如Exception(String message, Throwable cause))。不然，你將會丟失原始異常的 stack trace 與信息，這會使你分析致使異常的事件變得十分困難。

public void wrapException(String input) throws MyBusinessException {
    try {
        // do something
    } catch (NumberFormatException e) {
        throw new MyBusinessException("A message that describes the error.", e);
    }
}