本文著重介紹了 Java 異常選擇和使用中的一些誤區，希望各位讀者能夠熟練掌握異常處理的一些注意點和原則，注意總結和歸納。只有處理好了異常，才能提升開發人員的基本素養，提高系統的健壯性，提升用戶體驗，提高產品的價值。

誤區一、異常的選擇

圖 1. 異常分類

圖 1 描述了異常的結構，其實我們都知道異常分檢測異常和非檢測異常，但是在實際中又混淆了這兩種異常的應用。由于非檢測異常使用方便，很多開發人員就認為檢測異常沒什么用處。其實異常的應用情景可以概括為以下：

一、調用代碼不能繼續執行，需要立即終止。出現這種情況的可能性太多太多，例如服務器連接不上、參數不正確等。這些時候都適用非檢測異常，不需要調用代碼的顯式捕捉和處理，而且代碼簡潔明了。

二、調用代碼需要進一步處理和恢復。假如將 SQLException 定義為非檢測異常，這樣操作數據時開發人員理所當然的認為 SQLException 不需要調用代碼的顯式捕捉和處理，進而會導致嚴重的 Connection 不關閉、Transaction 不回滾、DB 中出現臟數據等情況，正因為 SQLException 定義為檢測異常，才會驅使開發人員去顯式捕捉，并且在代碼產生異常后清理資源。當然清理資源后，可以繼續拋出非檢測異常，阻止程序的執行。根據觀察和理解，檢測異常大多可以應用于工具類中。

誤區二、將異常直接顯示在頁面或客戶端。

將異常直接打印在客戶端的例子屢見不鮮，以 JSP 為例，一旦代碼運行出現異常，默認情況下容器將異常堆棧信息直接打印在頁面上。其實從客戶角度來說，任何異常都沒有實際意義，絕大多數的客戶也根本看不懂異常信息，軟件開發也要盡量避免將異常直接呈現給用戶。

清單 1

package com.ibm.dw.sample.exception;

/**

* 自定義 RuntimeException

* 添加錯誤代碼屬性

*/

public class RuntimeException extends java.lang.RuntimeException {

//默認錯誤代碼

public static final Integer GENERIC = 1000000;

//錯誤代碼

private Integer errorCode;

public RuntimeException（Integer errorCode， Throwable cause） {

this（errorCode， null， cause）;

}

public RuntimeException（String message， Throwable cause） {

//利用通用錯誤代碼

this（GENERIC， message， cause）;

}

public RuntimeException（Integer errorCode， String message， Throwable cause） {

super（message， cause）;

this.errorCode = errorCode;

}

public Integer getErrorCode（） {

return errorCode;

}

}

正如示例代碼所示，在異常中引入錯誤代碼，一旦出現異常，我們只要將異常的錯誤代碼呈現給用戶，或者將錯誤代碼轉換成更通俗易懂的提示。其實這里的錯誤代碼還包含另外一個功能，開發人員亦可以根據錯誤代碼準確的知道了發生了什么類型異常。

誤區三、對代碼層次結構的污染

我們經常將代碼分 Service、Business Logic、DAO 等不同的層次結構，DAO 層中會包含拋出異常的方法，如清單 2 所示：

清單 2

public Customer retrieveCustomerById（Long id） throw SQLException {

//根據 ID 查詢數據庫

}

上面這段代碼咋一看沒什么問題，但是從設計耦合角度仔細考慮一下，這里的 SQLException 污染到了上層調用代碼，調用層需要顯式的利用 try-catch 捕捉，或者向更上層次進一步拋出。根據設計隔離原則，我們可以適當修改成：

清單 3

public Customer retrieveCustomerById（Long id） {

try{

//根據 ID 查詢數據庫

}catch（SQLException e）{

//利用非檢測異常封裝檢測異常，降低層次耦合

throw new RuntimeException（SQLErrorCode， e）;

}finally{

//關閉連接，清理資源

}

}