Java 異常處理最佳實踐：分類策略、Design by Contract、斷言機制與 AOP 統一攔截

異常三層分類

Design by Contract (DbC) 思想

• 方法調用雙方存在「契約」：調用方保證前置條件，被調用方保證後置條件與類不變式。
• 例：setMonth(int m) 不應檢查 1<=m<=12，這是調用方責任；方法只保證調用後 month 正確設置且對象狀態合法。
• 職責邊界清晰 → 代碼更簡潔、錯誤更早暴露（在調用端）。

Java 斷言機制

JDK 1.4 引入 assert 關鍵字，編譯需 -source 1.4，運行需 -ea 啟用。

public void setMonth(int month) {
    assert month > 0 && month < 13 : \"月份非法: \" + month;  // 前置條件
    this.month = month;
    assert invariant() : \"對象狀態不一致\";  // 後置條件/不變式
}

最佳實踐：

• 開發/測試環境全程開啟 -ea，盡早暴露契約違反。
• 生產環境關閉斷言（默認關閉），零性能開銷。
• 不檢查 public API 參數（跨模塊邊界），僅用於內部契約驗證。
• 斷言失敗拋出 AssertionError（不可檢查異常），不應被捕獲處理。

異常體系設計參考 Spring

1. 統一根異常（如 DataAccessException）。
2. 包裝底層異常（SQLException 等），保留原始堆棧與信息。
3. 採用 RuntimeException 體系：
   • 免去 throws 聲明傳染。
   • 調用端非強制 try-catch，按需捕獲。
   • 與 Spring AOP 事務管理（拋出 RuntimeException 觸發回滾）天然契合。

AOP 統一異常攔截與日志

將「業務邏輯拋異常」與「記錄錯誤日志」解耦：

// 業務接口
public interface ITestService { void doSomething(); }

// 實現拋出運行時異常
public class TestServiceImpl implements ITestService {
    public void doSomething() { throw new RuntimeException(\"業務錯誤\"); }
}

// ThrowsAdvice 切面
public class LogAdvice implements ThrowsAdvice {
    public void afterThrowing(RuntimeException ex) {
        log.error(\"業務異常\", ex);  // 記錄日志
        // 不吞噬異常，繼續拋出保持原有流程
    }
}

// Spring 配置


    
    com.company.ITestService
    throwsAdvisor

效果：業務代碼零日志代碼，切面自動織入，異常透傳不阻斷。耦合從代碼移至配置，符合關注點分離原則。

總結建議

1. 建立清晰的三層異常體系，語義分明。
2. 內部契約用 assert，外部邊界用驗證異常。
3. 優先 RuntimeException，配合 AOP 統一橫切關注點（日志、事務、監控、轉換）。
4. 保留原始堆棧，錯誤信息面向用戶本地化。