企業級 Java 異常處理框架設計：嵌套異常與層次化架構

痛點：低層異常外洩污染業務層

許多企業應用直接拋出 RemoteException、NamingException 等系統級異常到 Web 層，導致前端無法理解業務語義，也難以優雅處理。正確做法是：系統層拋系統異常，業務層拋業務異常，兩者透過異常鏈關聯。

核心模式：嵌套異常

自訂 ApplicationException 作為基礎業務異常，內部攜帶 cause 欄位保存原始低層異常：

public class ApplicationException extends Exception {
    private Throwable cause;
    public ApplicationException(String msg, Throwable cause) {
        super(msg);
        this.cause = cause;
    }
    // 重寫 getMessage/printStackTrace 遞歸輸出完整鏈路
    @Override public String getMessage() {
        String msg = super.getMessage();
        Throwable child = cause;
        while (child != null) {
            if (child.getMessage() != null) msg += ": " + child.getMessage();
            if (child instanceof ApplicationException) break;
            child = getNestedException(child);
        }
        return msg;
    }
}

異常層次化設計

建立「通用 → 業務領域 → 具體場景」三層結構：

ApplicationException (基礎)
├── BusinessException (業務通用)
│   ├── InsufficientFundsException (具體：餘額不足)
│   └── NoSuchBookException (具體：書籍不存在)
│       └── BackorderedException (更細粒度：缺貨訂購)
└── SystemUnavailableException (系統級：服務不可用)

每個具體異常只需提供語義化建構子：

public class NoSuchBookException extends BusinessException {
    public NoSuchBookException(String book, String library) {
        super("書籍《" + book + "》在「" + library + "」館藏中不存在");
    }
}

分層拋轉策略

• EJB/DAO 層：捕獲 SQLException 等，包裝為 SystemUnavailableException 拋出
• Service 層：業務驗證失敗直接拋 InsufficientFundsException 等業務異常
• Web/Controller 層：統一攔截，業務異常轉友善提示，系統異常記錄日誌並顯示通用錯誤頁

效益總結

1. 語義清晰：前端拿到的是「餘額不足」而非「SQL 鎖等待超時」
2. 追蹤完整：堆疊資訊保留完整因果鏈，排查零盲區
3. 擴展低成本：新增業務異常只需繼承並寫建構子，無樣板代碼

投資一套深思熟慮的異常模型，能為專案長期維護節省無數除錯工時。