EJB 異常處理最佳實踐：從基礎原則到企業級解決方案

企業級系統對異常處理的嚴格要求

在生產環境中，異常處理不僅關乎代碼正確性，更直接影響用戶體驗與運維效率。理想的企業級異常處理應達成：

• 用戶端獲得清晰錯誤訊息與唯一錯誤碼，可對應客服系統
• 客服團隊即時收到告警，通過錯誤碼快速定位產品日誌至精確行號/方法
• 問題在設定時限內解決，用戶請求得到妥善處理

異常處理核心原則

1. 無法處理則不捕獲：避免吞沒異常導致錯誤隱藏
2. 捕獲必須妥善處理：記錄、轉換、重拋或恢復，不可空 catch
3. 就近捕獲原則：在最了解上下文的層級處理
4. 捕獲即記錄：除非打算重拋，否則必須在捕獲點記錄日誌
5. 方法粒度匹配異常粒度：根據所需處理精細度設計方法簽名
6. 應用異常分類盡可能精細：區分業務邏輯錯誤與系統故障

原則 1 與 3 看似衝突，實則需平衡：在不丟失原始異常意圖的前提下，盡可能靠近拋出點捕獲。

日誌工具的必要性

System.out.println 存在嚴重缺陷：

• 同步磁碟 I/O 嚴重降低吞吐量
• 生產環境控制台可能重導向至空裝置 (/dev/null) 或無控制台 (NT Service)
• 日誌檔案隨伺服器重啟被覆寫
• 測試與生產代碼不一致 (若上線前移除)

解決方案：使用聲明式日誌框架 (如 Log4J)，實現零開銷關閉、分級記錄、多輸出目標。

EJB 異常體系與容器契約

兩大異常類別

Entity Bean 特殊規則

• ejbCreate/ejbFind 拋出應用異常 → 交易回滾
• 其他業務方法拋出應用異常 → 交易不回滾 (除非標記 setRollbackOnly)

常見反模式與改進方案

反模式 1：捕獲所有異常並包裝為單一應用異常

// 錯誤做法
try { ... } catch (Exception e) { throw new MyAppException(e); }

問題：丟失原始異常類型，客戶端無法區分業務錯誤與系統故障。

改進：保留原始異常鏈，僅包裝需轉換語義的異常。

反模式 2：在 finally 中清理資源時吞沒異常

// 錯誤做法
finally { try { conn.close(); } catch (SQLException ignore) {} }

改進：記錄清理失敗日誌，或使用 try-with-resources (Java 7+)。

最佳實踐模式

1. 基礎應用異常類別設計

public class AppException extends Exception {
    private final String errorCode;
    private final Object[] params; // 國際化參數
    
    public AppException(String errorCode, String msg, Throwable cause) {
        super(msg, cause);
        this.errorCode = errorCode;
    }
    // getters...
}

2. 統一異常處理攔截器 (EJB 3.0+ @Interceptor / 2.x 擴充)

• 系統異常：記錄完整堆疊、生成唯一追蹤 ID、回滾交易、轉換為通用錯誤碼返回客戶端
• 應用異常：記錄業務上下文、保留原始錯誤碼透傳

3. 客戶端錯誤碼映射表

建立統一錯誤碼註冊表 (如 ERR-1001: InsufficientBalance)，前後端共用，支援國際化訊息模板。

總結

卓越的 EJB 異常處理建立在：清晰的異常分類、聲明式日誌框架、容器契約的深度理解、統一的錯誤碼體系 之上。投資於異常處理基礎設施，將在系統全生命週期中大幅降低故障排查成本。