處理 Exception 的幾種實踐，很優雅，被很多團隊採納！

Java程式設計大本營發表於2021-03-25
Exception

在Java中處理異常並不是一個簡單的事情。不僅僅初學者很難理解，即使一些有經驗的開發者也需要花費很多時間來思考如何處理異常，包括需要處理哪些異常，怎樣處理等等。

這也是絕大多數開發團隊都會制定一些規則來規範對異常處理的原因。而團隊之間的這些規範往往是截然不同的。

本文給出幾個被很多團隊使用的異常處理最佳實踐。

實踐

在Finally塊中清理資源或者使用try-with-resource語句

當使用類似InputStream這種需要使用後關閉的資源時，一個常見的錯誤就是在try塊的最後關閉資源。

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

上述程式碼在沒有任何exception的時候執行是沒有問題的。但是當try塊中的語句丟擲異常或者自己實現的程式碼丟擲異常，那麼就不會執行最後的關閉語句，從而資源也無法釋放。

合理的做法則是將所有清理的程式碼都放到finally塊中或者使用try-with-resource語句.
另外，關注公眾號「Java程式設計大本營」，在後臺回覆：面試，可以獲取我整理的 2021年最新java 系列面試題和答案，非常齊全。

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

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

指定具體的異常

儘可能的使用最具體的異常來宣告方法，這樣才能使得程式碼更容易理解。

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

如上，NumberFormatException字面上即可以看出是數字格式化錯誤。

對異常進行文件說明

當在方法上宣告丟擲異常時，也需要進行文件說明。和前面的一點一樣，都是為了給呼叫者提供儘可能多的資訊，從而可以更好地避免/處理異常。在Javadoc中加入throws宣告，並且描述丟擲異常的場景。

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

丟擲異常的時候包含描述資訊

在丟擲異常時，需要儘可能精確地描述問題和相關資訊，這樣無論是列印到日誌中還是監控工具中，都能夠更容易被人閱讀，從而可以更好地定位具體錯誤資訊、錯誤的嚴重程度等。

但這裡並不是說要對錯誤資訊長篇大論，因為本來Exception的類名就能夠反映錯誤的原因，因此只需要用一到兩句話描述即可。

try {
    new Long("xyz");
} catch (NumberFormatException e) {
    log.error(e);
} catch(Exception e ){
    log.error("describle exption's information... ",e)
}

NumberFormatException即告訴了這個異常是格式化錯誤，異常的額外資訊只需要提供這個錯誤字串即可。當異常的名稱不夠明顯的時候，則需要提供儘可能具體的錯誤資訊。

首先捕獲最具體的異常

現在很多IDE都能智慧提示這個最佳實踐，當你試圖首先捕獲最籠統的異常時，會提示不能達到的程式碼。當有多個catch塊中，按照捕獲順序只有第一個匹配到的catch塊才能執行。因此，如果先捕獲IllegalArgumentException，那麼則無法執行到對NumberFormatException的捕獲。

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

不要捕獲Throwable

Throwable是所有異常和錯誤的父類。你可以在catch語句中捕獲，但是永遠不要這麼做。如果catch了throwable，那麼不僅僅會捕獲所有exception，還會捕獲error。而error是表明無法恢復的jvm錯誤。因此除非絕對肯定能夠處理或者被要求處理error，不要捕獲throwable。

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

不要忽略異常

很多時候，開發者很有自信不會丟擲異常，因此寫了一個catch塊，但是沒有做任何處理或者記錄日誌。

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)

如上所示，後面的日誌也沒有附加更有用的資訊。如果想要提供更加有用的資訊，
那麼可以將異常包裝為自定義異常。因此，僅僅當想要處理異常時才去捕獲，否則只需要在方法簽名中宣告讓呼叫者去處理。

包裝異常時不要拋棄原始的異常

捕獲標準異常幷包裝為自定義異常是一個很常見的做法。這樣可以新增更為具體的異常資訊並能夠做針對的異常處理。

需要注意的是，包裝異常時，一定要把原始的異常設定為cause(Exception有構造方法可以傳入cause)。否則，丟失了原始的異常資訊會讓錯誤的分析變得困難。

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

總結

綜上可知，當丟擲或者捕獲異常時，有很多不一樣的東西需要考慮。其中的許多點都是為了提升程式碼的可閱讀性或者api的可用性。

異常不僅僅是一個錯誤控制機制，也是一個溝通媒介，因此與你的協作者討論這些最佳實踐並制定一些規範能夠讓每個人都理解相關的通用概念並且能夠按照同樣的方式使用它們。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章