高效 Java 異常處理：從「檢查 vs 不檢查」到「應變 vs 故障」的架構重構

Java 異常模型爭議由來已久。本文指出：問題不在語言機制，而在類庫設計混淆了應變與故障兩類根本不同的失敗語義。通過將異常語義對齊業務與系統邊界，建立故障屏障與應變傳播雙軌架構，實現代碼簡潔、診斷完整、業務語義清晰的異常治理體系。

核心定義：應變 vs 故障

為何受檢異常被濫用？

JDK 大量將故障（如 IOException、SQLException）建模為受檢異常，導致：

• 業務代碼被大量 try-catch 污染，實際無法處理。
• 為了編譯通過，被迫「拋出」或「吞沒」，導致異常丟失或簽名洩露實現細節。
• Spring、Hibernate 3.0+、JDO 等現代框架均轉向非受檢異常，驗證了此判斷。

架構級對策：雙軌制

軌道一：故障屏障

• 定義單一 FaultException extends RuntimeException（Java 1.4+ 支持異常鏈 initCause）。
• 所有受檢異常在邊界（DAO、外部調用）捕獲 → 包裝為 FaultException → 拋出。
• 應用頂層（Struts ExceptionHandler、Spring SimpleMappingExceptionResolver、Servlet Filter、AOP 切面）統一捕獲，完成：
  ① 記錄完整堆棧與診斷信息到日志系統；
  ② 返回友好通用錯誤頁/JSON/ SOAP Fault；
  ③ 可選：告警通知運維。
• 業務代碼零故障處理代碼，專注核心邏輯。

軌道二：應變傳播

• 為每種業務應變定義專用受檢異常：InsufficientFundsException、StopPaymentException。
• 異常攜帶業務上下文對象（如 OverdraftProtection），調用者可直接決策（轉賬、拒絕、記賬）。
• 編譯器強制調用者處理，確保業務流程完整性。
• 不記業務日志：應變是正常流程，僅在極少數關鍵節點（審計、風控）按需記錄。

AOP 視角：橫切關注點的終極歸宿

故障屏障天然是橫切關注點。使用 AspectJ/Spring AOP：

• 切點：所有公共服務方法執行。
• 通知：環繞通知捕獲 FaultException 及其子類，執行統一處理邏輯。
• 業務代碼完全解耦故障處理基礎設施，無需繼承基類或實現接口。

應變異常屬於業務邏輯一部分，通常不建議用 AOP 攔截，保持顯式傳播。

決策速查表

1. 這個失敗是否屬於方法契約承諾的「可能結果」？→ 是 → 受檢異常（應變）。
2. 調用者是否有具體業務動作應對？→ 是 → 受檢異常。
3. 否 → 非受檢異常（故障），拋向故障屏障。

結語

正確使用 Java 異常模型的關鍵在於語義分類而非語法偏好。將「應變」建模為受檢異常，「故障」建模為非受檢異常並交給故障屏障，配合 AOP 封裝橫切邏輯，即可獲得：業務代碼純淨、診斷信息完整、架構邊界清晰的異常治理體系。