Java 中的異常處理機制
本篇文章主要介紹了
- Java 中的異常
- 如何處理函數拋出的異常
- 處理異常的原則
- 異常處理時，性能開銷大的地方
Java 語言在設計之初就提供了相對完善的異常處理機制。
我們首先介紹一下 Java 中的異常。
介紹 Java 中的異常
異常是程式在運行過程中出現的程式異常事件，異常會中斷正在執行的正常指令流 。
Java 中的異常分為兩大類：Exception 和 Error。
下面是 Exception 和 Error 的類定義
public class Exception extends Throwable {}
public class Error extends Throwable {}
Exception 和 Error 都繼承了 Throwable 類，在 Java 中只有 Throwable 類型的實例才可以被拋出（throw）或者被捕獲（catch）。
Exception 和 Error 體現了 Java 平台設計者對不同異常情況的分類。
下面我們逐一介紹 Error 和 Exception。
介紹 Error
Error 類對象一般是由虛擬機生成並拋出，絕大部分的 Error 都會導致虛擬機自身處於不可恢復的狀態，是程式無法控制和處理的。當出現 Error 時，一般會選擇終止執行緒。
Error 中最常見的是虛擬機運行錯誤（VirtualMachineError 抽象類）。
虛擬機運行錯誤中最常見的有：
- 記憶體溢出（OutOfMemoryError）：由於記憶體不足，虛擬機沒有可分配的記憶體了，垃圾回收器也不能釋放更多的記憶體，那麼虛擬機拋出 OutOfMemoryError
- 棧溢出（StackOverflowError）：如果一個執行緒已用的棧大小 超過 配置的允許最大的棧大小，那麼虛擬機拋出 StackOverflowError
介紹 Exception
Exception 有兩種類型「編譯時異常」和「運行時異常」
- 「編譯時異常」對應 Java 的 Exception 類
- 「運行時異常」對應 Java 的 RuntimeException 類（RuntimeException 類繼承 Exception 類 ）
下面是 Exception、RuntimeException 類的定義
public class Exception extends Throwable {}
public class RuntimeException extends Exception {}
對於「運行時異常」，我們在編寫程式碼的時候，可以不用主動去 try-catch 捕獲（不強制要求），編譯器在編譯程式碼的時候，並不會檢查程式碼是否有對運行時異常做了處理。
相反，對於「編譯時異常」，我們在編寫程式碼的時候，必須主動去 try-catch 獲取 或者 在函數定義中聲明向上拋出異常（throws），否則編譯就會報錯。
所以：
- 「運行時異常」也叫作非受檢異常（Unchecked Exception）
- 「編譯時異常」也叫作受檢異常（Checked Exception）
在函數拋出異常的時候，，我們該怎麼處理呢？是吞掉還是向上拋出？
如果選擇向上拋出，我們應該選擇拋出哪種類型的異常呢？是受檢異常還是非受檢異常？
我們下文會對此介紹。
常見的編譯時異常有：
- FileNotFoundException：當嘗試打開由指定路徑表示的文件失敗時拋出
- ClassNotFoundException：當應用程式嘗試通過其字元串名稱載入類時拋出，以下三種方法載入
- Class.forName(java.lang.String)
- ClassLoader.findSystemClass(java.lang.String)
- ClassLoader.loadClass(java.lang.String, boolean)
常見的運行時異常有：
- 非法參數異常（IllegalArgumentException）：當傳入了非法或不正確的參數時拋出
- 空指針異常（NullPointerException）：當在需要對象的情況下使用了 null 時拋出。
- 下標訪問越界異常（IndexOutOfBoundsException）：當某種索引（例如數組，字元串或向量）的索引超出範圍時拋出。
- 類型轉換異常（ClassCastException）：當嘗試將對象轉換為不是實例的子類時拋出。
- 運算異常（ArithmeticException）：運算條件出現異常時拋出。例如，「除以零」的整數。
Java 異常類的結構
如何處理函數拋出的異常
在函數拋出異常的時候，我們該怎麼處理呢？是吞掉還是向上拋出？
如果選擇向上拋出，我們應該選擇拋出哪種類型的異常呢？是受檢異常還是非受檢異常？
下面我們就對此介紹。
吞掉 or 拋出
在函數拋出異常的時候，我們該怎麼處理？是吞掉還是向上拋出？
總結一下，在函數拋出異常的時候，一般有下面三種處理方法。
- 直接吞掉
- 原封不動地 re-throw
- 包裝成新的異常 re-throw
直接吞掉。具體的程式碼示例如下所示：
public void func1() throws Exception1 {
// ...
}
public void func2() {
//...
try {
func1();
} catch (Exception1 e) {
//吐掉：try-catch列印日誌
log.warn("...", e);
}
//...
}
原封不動地 re-throw。具體的程式碼示例如下所示：
public void func1() throws Exception1 {
// ...
}
//原封不動的re-throw Exception1
public void func2() throws Exception1 {
//...
func1();
//...
}
包裝成新的異常 re-throw。具體的程式碼示例如下所示：
public void func1() throws Exception1 {
// ...
}
public void func2() throws Exception2 {
//...
try {
func1();
} catch (Exception1 e) {
// wrap成新的Exception2然後re-throw
throw new Exception2("...", e);
}
//...
}
當我們面對函數拋出異常的時候，應該選擇上面的哪種處理方式呢？我總結了下面三個參考原則：
- 如果 func1() 拋出的異常是可以恢復，且 func2() 的調用方並不關心此異常，我們完全可以在 func2() 內將 func1() 拋出的異常吞掉；
- 如果 func1() 拋出的異常對 func2() 的調用方來說，也是可以理解的、關心的 ，並且在業務概念上有一定的相關性，我們可以選擇直接將 func1 拋出的異常 re-throw；
- 如果 func1() 拋出的異常太底層，對 func2() 的調用方來說，缺乏背景去理解、且業務概念上無關，我們可以將它重新包裝成調用方可以理解的新異常，然後 re-throw。
應該選擇上面的哪種處理方式，總結來說就是從以下兩個方面進行判斷：
- 函數1 拋出的異常是否可以恢復
- 函數1 拋出的異常對於 函數2 的調用方來說是否可以理解、關心、業務概念相關
總之，是否往上繼續拋出，要看上層程式碼是否關心這個異常。關心就將它拋出，否則就直接吞掉。
是否需要包裝成新的異常拋出，看上層程式碼是否能理解這個異常、是否業務相關。如果能理解、業務相關就可以直接拋出，否則就封裝成新的異常拋出。
對於處理函數拋出的異常，我們需要注意：
- 如果選擇吞掉函數拋出的異常的話，我們必須把異常輸出到日誌系統，方便後續診斷。
- 如果把異常輸出到日誌系統時，我們在保證診斷資訊足夠的同時，也要考慮避免包含敏感資訊，因為那樣可能導致潛在的安全問題。
如果我們看 Java 的標準類庫，你可能注意到類似 java.net.ConnectException，出錯資訊是類似「 Connection refused (Connection refused)」，而不包含具體的機器名、IP、埠等，一個重要考量就是資訊安全。
類似的情況在日誌中也有，比如，用戶數據一般是不可以輸出到日誌裡面的。
受檢異常 or 非受檢異常
在函數拋出異常的時候，如果選擇向上拋出，我們應該選擇拋出哪種類型的異常呢？是受檢異常還是非受檢異常？
對於程式碼 bug（比如下標訪問越界、空指針）以及不可恢復的異常（比如資料庫連接失敗），即便我們捕獲了，也做不了太多事情，我們希望程式能 fail-fast，所以，我們傾向於使用非受檢異常，將程式終止掉。
對於可恢復異常、業務異常，比如提現金額大於餘額的異常，我們更傾向於使用受檢異常，明確告知調用者需要捕獲處理。
處理異常的原則
盡量不要捕獲通用異常
盡量不要捕獲類似 Exception 這樣的通用異常，而應該捕獲特定異常（盡量縮小捕獲的異常範圍）。
下面舉例說明，實例程式碼如下：
try {
// 業務程式碼
// …
Thread.sleep(1000L);
} catch (Exception e) {
// Ignore it
}
對於 Thread.sleep() 函數拋出的 InterruptedException，我們不應該捕獲 Exception 通用異常，而應該捕獲 InterruptedException 這樣的特定異常。
這是因為我們要保證程式不會捕獲到我們不希望捕獲的異常。比如，我們更希望 RuntimeException 導致執行緒終止，而不是被捕獲。
不要生吞異常
不要生吞（swallow）異常，盡量把異常資訊記錄到日誌系統中。
這是異常處理中要特別注意的事情，因為生吞異常很可能會導致難以診斷的詭異情況。
如果我們沒有把異常拋出，也沒有把異常記錄到日誌系統，程式可能會在後續出現難以排查的 bug。沒人能夠輕易判斷究竟是哪裡拋出了異常，以及是什麼原因產生了異常。
再來看一段程式碼
try {
// 業務程式碼
// …
} catch (IOException e) {
e.printStackTrace();
}
這段程式碼作為一段實驗程式碼，是沒有任何問題的，但是在產品程式碼中，通常都不允許這樣處理。
你先思考一下這是為什麼呢？
我們先來看看 printStackTrace() 的文檔，開頭就是「Prints this throwable and its backtrace to the standard error stream」。問題就在這裡，在稍微複雜一點的生產系統中，標準出錯（STERR）不是個合適的輸出選項，因為你很難判到底輸出到哪裡去了。尤其是對於分散式系統，如果發生異常，但是無法找到堆棧軌跡（stacktrace），這純屬是為診斷設置障礙。
所以，最好使用產品日誌，詳細地將異常記錄到日誌系統里。
異常處理時，性能開銷大的地方
我們從性能角度來審視一下 Java 的異常處理機制，這裡有兩個性能開銷相對大的地方：
- try-catch 程式碼段會產生額外的性能開銷，或者換個角度說，它往往會影響 JVM 對程式碼進行優化，所以建議僅捕獲有必要的程式碼段，盡量不要一個大的 try 包住整段的程式碼；
- Java 每實例化一個 Exception，都會對當時的棧進行快照，這是一個相對比較重的操作。如果實例化 Exception 發生的非常頻繁，這個開銷可就不能被忽略了。
當我們的服務出現反應變慢、吞吐量下降的時候，檢查發生最頻繁的 Exception 也是一種思路。
參考文章
Exception和Error有什麼區別？
程式出錯該返回啥？NULL、異常、錯誤碼、空對象？
