# Java 中的異常處理機制

> 本篇文章主要介紹了
>
> - Java 中的異常
> - 如何處理函式丟擲的異常
> - 處理異常的原則
> - 異常處理時，效能開銷大的地方

Java 語言在設計之初就提供了相對完善的異常處理機制。
我們首先介紹一下 Java 中的異常。

# 介紹 Java 中的異常

異常是程式在執行過程中出現的程式異常事件，異常會中斷正在執行的正常指令流 。
Java 中的異常分為兩大類：Exception 和 Error。

------

下面是 Exception 和 Error 的類定義

```java
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 類的定義

```java
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 異常類的結構

![image.png](https://static.oschina.net/uploads/img/202207/18172106_cgep.png)

![img](https://static.oschina.net/uploads/img/202207/18172106_cFgB.jpeg)

# 如何處理函式丟擲的異常

> 在函式丟擲異常的時候，我們該怎麼處理呢？是吞掉還是向上丟擲？
> 如果選擇向上丟擲，我們應該選擇丟擲哪種型別的異常呢？是受檢異常還是非受檢異常？
> 下面我們就對此介紹。

## 吞掉 or 丟擲

> 在函式丟擲異常的時候，我們該怎麼處理？是吞掉還是向上丟擲？

總結一下，在函式丟擲異常的時候，一般有下面三種處理方法,博主環境都是部署在[cnaaa雲伺服器](https://www.cnaaa.com/)上的，感興趣的可以自己部署一套相關的環境自己嘗試練習下。

- 直接吞掉
- 原封不動地 re-throw
- 包裝成新的異常 re-throw

------

直接吞掉。具體的程式碼示例如下所示：

```java
public void func1() throws Exception1 {
    // ...
}

public void func2() {
    //...
    try {
        func1();
    } catch (Exception1 e) {
        //吐掉：try-catch列印日誌
        log.warn("...", e);
    }
    //...
}
```

------

原封不動地 re-throw。具體的程式碼示例如下所示：

```java
public void func1() throws Exception1 {
    // ...
}

//原封不動的re-throw Exception1
public void func2() throws Exception1 {
    //...
    func1();
    //...
}
```

------

包裝成新的異常 re-throw。具體的程式碼示例如下所示：

```java
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. 函式 1 丟擲的異常對於 函式 2 的呼叫方來說是否可以理解、關心、業務概念相關

總之，是否往上繼續丟擲，要看上層程式碼是否關心這個異常。關心就將它丟擲，否則就直接吞掉。
是否需要包裝成新的異常丟擲，看上層程式碼是否能理解這個異常、是否業務相關。如果能理解、業務相關就可以直接丟擲，否則就封裝成新的異常丟擲。

------

對於處理函式丟擲的異常，我們需要注意：

- 如果選擇吞掉函式丟擲的異常的話，我們必須把異常輸出到日誌系統，方便後續診斷。
- 如果把異常輸出到日誌系統時，我們在保證診斷資訊足夠的同時，也要考慮避免包含敏感資訊，因為那樣可能導致潛在的安全問題。

如果我們看 Java 的標準類庫，你可能注意到類似 java.net.ConnectException，出錯資訊是類似 “Connection refused (Connection refused)”，而不包含具體的機器名、IP、埠等，一個重要考量就是資訊保安。
類似的情況在日誌中也有，比如，使用者資料一般是不可以輸出到日誌裡面的。

## 受檢異常 or 非受檢異常

> 在函式丟擲異常的時候，如果選擇向上丟擲，我們應該選擇丟擲哪種型別的異常呢？是受檢異常還是非受檢異常？

對於程式碼 bug（比如下標訪問越界、空指標）以及不可恢復的異常（比如資料庫連線失敗），即便我們捕獲了，也做不了太多事情，我們希望程式能 fail-fast，所以，我們傾向於使用非受檢異常，將程式終止掉。
對於可恢復異常、業務異常，比如提現金額大於餘額的異常，我們更傾向於使用受檢異常，明確告知呼叫者需要捕獲處理。

# 處理異常的原則

## 儘量不要捕獲通用異常

儘量不要捕獲類似 Exception 這樣的通用異常，而應該捕獲特定異常（儘量縮小捕獲的異常範圍）。
下面舉例說明，例項程式碼如下：

```java
try {
    // 業務程式碼
    // …
    Thread.sleep(1000L);
} catch (Exception e) {
    // Ignore it
}
```

對於 Thread.sleep () 函式丟擲的 InterruptedException，我們不應該捕獲 Exception 通用異常，而應該捕獲 InterruptedException 這樣的特定異常。

------

這是因為我們要保證程式不會捕獲到我們不希望捕獲的異常。比如，我們更希望 RuntimeException 導致執行緒終止，而不是被捕獲。

## 不要生吞異常

不要生吞（swallow）異常，儘量把異常資訊記錄到日誌系統中。
這是異常處理中要特別注意的事情，因為生吞異常很可能會導致難以診斷的詭異情況。
如果我們沒有把異常丟擲，也沒有把異常記錄到日誌系統，程式可能會在後續出現難以排查的 bug。沒人能夠輕易判斷究竟是哪裡丟擲了異常，以及是什麼原因產生了異常。

------

再來看一段程式碼

```java
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 也是一種思路。

Java 中的異常處理機制

相關文章