Java 異常處理大辯論：檢查型 vs 非檢查型，誰才是正統？

Java 異常機制獨創檢查型異常，編譯器強制聲明或捕獲。早期正統觀點（Sun 教程、《Effective Java》）推崇「優先用檢查型異常表示可恢復錯誤，運行時異常僅用於編程錯誤」。但近年 Bruce Eckel、Rod Johnson 等大佬公開反水，C# 更直接取消檢查型異常。本文梳理雙方核心論點，助你在項目中做出理性選擇。

傳統正統觀點：檢查型異常是「契約一部分」

• 文檔化預期失敗：方法簽名 throws IOException 明確告知調用者「可能失敗且你應處理」
• 強制處理：編譯器不允許忽略，避免錯誤被吞噬
• 語義分類：
  • 檢查型 = 可恢復的業務/環境錯誤（文件不存在、網絡中斷、權限不足）
  • 非檢查型 = 編程 Bug（空指針、越界、除零、非法參數）

Bloch 《Effective Java》四大鐵律：

1. 只用於異常狀況，別用於控制流
2. 可恢復用檢查型，Bug 用運行時異常
3. 避免濫用檢查型（調用者無法恢復或只會退出時）
4. 拋出與抽象層級匹配的異常（異常鏈保留根因）

反叛聲音：檢查型異常的「七宗罪」

1. 暴露實現細節，破壞封裝

DAO 方法拋 SQLException，Service 層被迫捕獲或繼續拋，導致上層業務代碼耦合底層存儲技術。違反「拋出與抽象匹配」原則。

2. API 膨脹與版本地獄

接口新增一個檢查型異常，所有實現類、所有調用鏈必須修改簽名。接口演化極其痛苦。

3. 捕獲即吞噬的反模式泛濫

try {
    riskyCall();
} catch (CheckedException e) {
    // 沒辦法，只能印日誌或包裝成 RuntimeException 拋出
    throw new RuntimeException(e);
}

大量樣板代碼，真正錯誤處理邏輯反而被淹沒。

4. Lambda/Stream 中極難處理

函數式接口不拋檢查型異常，迫使開發者寫「嘗試-捕獲-包裝」工具方法，代碼噪音大增。

5. 異常即控制流的誘惑

有人用檢查型異常實現業務分支（如 throw new InsufficientFundsException() 代替返回狀態），濫用異常機制。

雙方共識與折中方案

現代最佳實踐：領域驅動的異常設計

1. 業務異常 = 運行時異常：命名語義化（OrderNotFoundException、PaymentDeclinedException），攜帶業務關鍵數據（訂單 ID、錯誤代碼）。
2. 統一異常處理層：Controller/切面層統一捕獲、記錄、轉換為統一錯誤響應，業務代碼零 try-catch。
3. 異常鏈永不斷裂：throw new BizException("msg", cause)，保留完整堆疊追蹤。
4. 文檔化而非強制：用 Javadoc @throws 描述可能拋出的業務異常，而非靠編譯器強制。

結論：檢查型異常在 JDK 核心庫、IO、反射等底層 API 有其歷史合理性；但在業務應用層，領域運行時異常 + 統一處理機制，才是更高效、可維護的選擇。