Java 異常處理機制全景指南：體系架構、捕獲策略與最佳實踐

前言：異常是程序的「體檢報告」

Java 通過面向對象方式統一處理程序錯誤。異常機制將「正常業務流」與「錯誤處理流」分離，強制調用者面對可能失敗的操作。本文系統梳理異常繼承體系、受檢/非受檢分類、拋捕鏈傳播規則、自定義異常設計、核心 API 使用，並給出生產級最佳實踐清單。

一、異常體系架構圖譜

java.lang.Throwable (所有異常共同祖先)
├── java.lang.Error (錯誤) — JVM 層面嚴重問題，程序不應捕獲
│   ├── VirtualMachineError (VM 錯誤)
│   │   ├── OutOfMemoryError (堆/元空間 OOM)
│   │   └── StackOverflowError (棧溢出)
│   ├── NoClassDefFoundError (類定義缺失)
│   └── LinkageError (鏈接錯誤)
└── java.lang.Exception (異常) — 程序可處理的業務/邏輯異常
    ├── java.lang.RuntimeException (運行時異常) — 非受檢，編譯器不強制處理
    │   ├── NullPointerException (空指針)
    │   ├── IllegalArgumentException (參數非法)
    │   ├── IndexOutOfBoundsException (越界)
    │   └── ArithmeticException (算術錯誤，如除零)
    └── 其他 Exception 子類 — 受檢異常，必須 try-catch 或 throws
        ├── IOException (IO 錯誤)
        ├── SQLException (數據庫錯誤)
        ├── ClassNotFoundException (類未找到)
        └── 自定義業務異常 (extends Exception)

二、核心概念辨析

三、異常拋捕與傳播鏈

3.1 拋出：`throw` vs `throws`

• `throw new MyException("msg")` — 方法內拋出具體異常對象，終止當前執行路徑。
• `throws MyException, IOException` — 方法簽名聲明拋出類型，將責任轉給調用者。

3.2 捕獲：`try-catch-finally` 語法糖

try {
    int result = quotient(3, -1); // 可能拋 MyException / ArithmeticException
} catch (MyException e) {         // 精確捕獲：先捕獲子類
    logger.warn("業務規則違反: {}", e.getMessage());
} catch (ArithmeticException e) { // 再捕獲同級其他
    logger.error("除數為零", e);
} catch (Exception e) {           // 最後捕獲父類 (兜底)
    logger.error("未知異常", e);
} finally {
    // 無論是否異常，必執行 (除非 System.exit / JVM 崩潰)
    resource.close();
}

3.3 異常鏈：保留原始堆棧

try {
    // 低層操作
} catch (SQLException e) {
    // 包裝為業務異常，保留 cause
    throw new BizException("用戶查詢失敗", e); // 關鍵：傳入 cause
}
// 異常鏈傳播：quotient() → main() → JVM
// printStackTrace() 會完整打印：BizException → SQLException → ...

3.4 捕獲順序鐵律

子類在前，父類在後。若 `catch (Exception e)` 寫在 `catch (MyException e)` 前，後者永不可達，編譯器報錯「exception MyException has already been caught」。

四、自定義異常設計規範

4.1 何時自定義？

• 業務邏輯特有錯誤（如「餘額不足」、「訂單狀態非法」）。
• 需要攜帶額外上下文信息（錯誤碼、字段名、請求 ID）。
• 需區分不同錯誤類型以便上層差異化處理。

4.2 標準模板

public class BizException extends Exception {
    private final int errorCode; // 業務錯誤碼
    public BizException(String message, int errorCode) {
        super(message); this.errorCode = errorCode;
    }
    public BizException(String message, Throwable cause, int errorCode) {
        super(message, cause); this.errorCode = errorCode;
    }
    public int getErrorCode() { return errorCode; }
}

// 使用
throw new BizException("餘額不足", ErrorCode.INSUFFICIENT_BALANCE);

4.3 繼承選擇原則

• 繼承 `Exception` → 受檢異常，強制調用者處理，適合可預期、可恢復的業務異常。
• 繼承 `RuntimeException` → 非受檢，適合編程錯誤、不可恢復、不應被捕獲的場景（如參數校驗失敗）。

五、核心 API 快速查閱

六、生產級最佳實踐清單

1. 異常用於「異常」情況，不用於正常流程控制（如循環終止）。
2. 盡早拋出，遲捕獲：低層拋出具體異常，高層統一捕獲轉碼/記錄/響應。
3. 包裝而非吞噬：`catch (SQLException e) { throw new BizException("...", e); }` 保留堆棧。
4. 資源釋放用 try-with-resources (Java 7+)：

   try (Connection c = ds.getConnection(); PreparedStatement ps = c.prepareStatement(sql)) {
       // 自動 close，即使異常也安全
   }

5. 避免巨大 try 塊：精確包裹可能拋異常的語句，便於定位。
6. 日誌記錄異常全信息：`log.error("msg", e)` 而非 `log.error(e.getMessage())`。
7. 定義清晰的錯誤碼體系：便於前端國際化、監控告警、客服排查。
8. 不要在 finally 中拋異常/返回值：會掩蓋 try/catch 中的原始異常。
9. 受檢異常不濫用：穩定 API 層轉為非受檢或結果封裝 (`Result`)，減少樣板代碼。

七、try-with-resources 進階：多資源與 Suppressed Exceptions

try (InputStream in = new FileInputStream("a.txt");
     OutputStream out = new FileOutputStream("b.txt")) {
    // 複制邏輯
} catch (IOException e) {
    // 若 in.close() 也拋異常，會被 suppressed 附加在 e 上
    for (Throwable t : e.getSuppressed()) logger.warn("Suppressed: {}", t);
}

總結

Java 異常機制以 `Throwable` 為根，分 `Error`(不可控) 与 `Exception`(可控)，再分 `RuntimeException`(編程錯誤) 与 受檢異常(API 契約)。掌握拋捕傳播規則、異常鏈保留、自定義分層設計、try-with-resources 資源安全，配合「盡早拋出、遲捕獲、包裝不吞噬、日誌全信息」原則，即可構建健壯、可診斷、易維護的異常處理體系。