J2EE 分層架構異常處理最佳實踐：從 DAO 到展示層的完整策略

異常處理是 Java 開發者日常必面對的課題，但許多人缺乏系統性原則：遇到受檢異常就胡亂 try-catch 加 printStackTrace()，運行時異常則直接忽略。這種做法除除錯略有幫助外，實務上毫無價值。本文從 Java 異常體系入手，針對 J2EE 典型四層架構 (DAO、業務、控制、展示) 提出具體處理準則。

Java 異常體系速覽

Throwable (受檢)
├── Error (非受檢) - 嚴重系統錯誤，應用不應捕獲
├── Exception (受檢) - 應用層級異常
│   └── RuntimeException (非受檢) - 程式邏輯錯誤 (NullPointer, IllegalArgument...)

• 受檢異常： Exception 及其子類 (排除 RuntimeException)，編譯器強制處理
• 非受檢/運行時異常： RuntimeException 及其子類，編譯器不強制
• Throwable/Error 通常用於基礎框架層，業務代碼少見

分層異常處理策略

一、DAO 層：轉譯為非受檢異常向上傳播

場景： 使用原生 JDBC 無法避免 SQLException；若用 Spring JDBC Template 則無受檢異常拋出，代碼更優雅。

原則： 捕獲底層異常 (如 SQLException)，包裝拋出自訂非受檢異常 (繼承 RuntimeException)。

優勢：

1. 介面不被污染： DAO 介面不宣告 throws SQLException，日後換用 Spring/ORM 介面無需變動
2. 錯誤資訊保留： 原始異常作為 cause 傳遞，便於上層追蹤根因

粒度建議： 模組級別定義一個 DAO 運行時異常 (如 ModuleXxxDAORuntimeException)，而非每個 DAO 方法/類別各定義一個。過度細粒度導致 Service 層捕獲大量異常類別，代碼混亂難維護。

// 推薦做法
throw new OrderDAORuntimeException("查詢訂單失敗", sqlException);

// 避免：為每個 DAO 定義獨立異常類別

二、業務層 (Service)：轉譯與業務異常區分

核心原則： Service 方法代表一個完整業務單元，應包含完整交易邊界。避免「Controller 調用多個 Service 完成一業務」的反模式 (交易應在 Service 層管理)。

處理策略：

• 模組級定義 XxxServiceRuntimeException 捕獲不可避免的底層異常轉譯拋出
• 前端框架 (Struts2、Spring MVC) 會自動攔截 Service 異常交由開發者處理
• 特殊業務規則要求特定異常處理時，可拋出帶有業務語義的非受檢異常 (但不推薦濫用)

口訣： 「盡可能不讓異常污染 Service 介面！」

三、控制層 (Action/Controller)：框架托管，專注資源安全

主流 MVC 框架 (Struts2、Spring MVC) 已內建異常攔截機制，控制層通常聲明 throws Exception 由框架統一處理。開發者僅需關注：

• 調用非受檢異常方法 (如 IO 操作) 時的資源釋放 (流關閉等)
• 透過框架提供的異常映射配置導向錯誤頁面

四、展示層：用戶友善為優先

處理方式依需求彈性選擇：

1. 不處理： 異常直接拋出，容器顯示預設錯誤頁 (體驗差)
2. 定義錯誤頁： 根據異常類型/模組導向友善錯誤頁 (推薦基礎做法)
3. 模板級捕獲： 視圖模板 (如 Velocity、Freemarker) 捕獲異常將錯誤資訊內嵌頁面特定位置 (最友善、複雜度最高)

總結：五大核心準則

1. 嚴禁吞沒異常： 捕獲後不處理 (空 catch 或僅 printStackTrace) 會導致排查無從下手
2. 介面乾淨原則： 多層架構中，盡量避免受檢異常污染層間介面，善用非受檢異常傳播
3. 粒度適中： 異常類別按模組/業務領域粗粒度定義，避免爆炸性增加
4. 保留因果鏈： 拋出新異常時務必帶上原始異常 (new MyException(msg, cause))
5. 分層職責清晰： DAO 轉譯、Service 業務語義、Controller 資源安全、View 用戶體驗

以上觀點僅代表個人實務經驗，歡迎交流探討。
出處：https://lavasoft.blog.51cto.com/62575/244138