Java 異常處理體系全景指南：架構解析、最佳實踐與九條鐵律

Java 異常機制是構建健壯系統的基石。本文系統梳理異常架構體系、關鍵字語義、三大異常分類，並依據《Effective Java》提煉九條生產級異常處理鐵律，附帶代碼反例與性能實測，助你告別「try-catch 大法好」的濫用誤區。

一、 異常關鍵字語義速查

二、 異常架構體系圖解

Throwable
├── Error          // 嚴重錯誤，應用無法恢復（OOM, StackOverflow）
└── Exception      // 可預期、可恢復的異常情況
    ├── RuntimeException  // 非受檢異常：編譯器不強制處理（NPE, 索引越界）
    └── 其他 Exception    // 受檢異常：編譯器強制 try-catch 或 throws（IO, SQL）

三、 三大異常分類決策指南

原則：可恢復 → 受檢異常；程序錯誤 → 運行時異常（《Effective Java》條目 70）。

四、 九條異常處理鐵律

鐵律 1：僅用於非正常情況

反例：用 IndexOutOfBoundsException 控制數組遍歷終止。實測：異常控制流比邊界判斷慢 2 倍以上（16ms vs 8ms/10000 次）。JVM 對異常路徑不優化，且阻礙 JIT 編譯優化。

鐵律 2：可恢復用受檢，編程錯誤用運行時

用戶餘額不足 → 受檢異常（業務可處理）；除數為零 → 運行時異常（代碼邏輯 Bug）。

鐵律 3：避免濫用受檢異常

API 方法拋出多個受檢異常會強制調用者編寫冗長 catch/throws。判斷標準：調用者能否通過代碼預防？調用者捕獲後能否有意義處理？雙否則改用運行時異常。

鐵律 4：優先復用標準異常

語義匹配優於名稱匹配，確保異常文檔描述的前提與拋出場景一致。

鐵律 5：異常轉譯保護封裝邊界

底層異常（如 NoSuchElementException）不應直接向上層拋出。高層捕獲後轉譯為符合其抽象語義的異常（如 IndexOutOfBoundsException），即 異常轉譯 模式：

public E get(int index) {
    try { return listIterator(index).next(); }
    catch (NoSuchElementException e) { throw new IndexOutOfBoundsException("Index: " + index); }
}

鐵律 6：文檔化每個拋出異常

Javadoc @throws 標簽記錄拋出條件。類級文檔可統一說明通用異常，避免重複。

鐵律 7：異常攜帶失敗上下文信息

自定義異常構造器接受參數（訂單號、用戶 ID、錯誤碼），toString() 包含關鍵診斷信息，堆棧跟蹤即可定位問題，無需再查日誌。

鐵律 8：追求失敗原子性

方法失敗後，對象狀態應保持調用前狀態。實現途徑：

1. 不可變對象（天然原子性）
2. 參數前置校驗（if (size==0) throw new EmptyStackException();）
3. 調整計算順序：先算可能失敗的，再修改狀態
4. 補償回滾代碼
5. 副本上操作，成功再替換原對象

文檔必須聲明違背原子性的狀態變更。

鐵律 9：絕不忽略異常

catch (Exception e) { } 等同於關閉火警報警器。最少應記錄日誌並說明忽略理由：

catch (SpecificException e) {
    log.debug("忽略非關鍵異常: {}", e.getMessage()); // 有理有據
}

五、 總結

異常處理不是樣板代碼堆砌，而是系統可靠性工程的核心環節。掌握架構分類、遵循九條鐵律、養成「異常即文檔」習慣，才能寫出既優雅又健壯的 Java 代碼。