1. 異常本質與分類
異常 = 程式執行時遇到的錯誤狀態或非預期行為。來源:代碼邏輯錯誤、資源不可用、JVM 內部異常等。Java 採用類 C++ 異常模型,但更強制、更規範。
傳統錯誤處理 vs 異常機制
| 維度 | 傳統錯誤碼/分散處理 | 異常機制 |
| 代碼清晰度 | 錯誤處理混雜業務邏輯 | 分離關注點,主流程清晰 |
| 錯誤傳遞 | 層層檢查返回值 | 自動向上冒泡至處理者 |
| 強制性 | 易被忽略 | 受檢異常編譯強制處理 |
| 效能 | 低開銷 | 建立堆疊追蹤有成本 |
2. 適用場景判斷
- ✅ 同步錯誤:陣列越界、除零、資源耗盡、無效參數
- ❌ 非同步事件:滑鼠點擊、鍵盤輸入、網路封包到達、磁碟 I/O 完成 → 應用事件監聽器模式
- ✅ 錯誤偵測與處理位置分離:庫方法拋出,上層業務邏輯捕獲處理
- ✅ 大型專案統一錯誤處理策略
- ✅ 元件化開發:介面契約包含異常宣告
3. 核心語法與流程
try {
// 風險代碼
} catch (SpecificException e) {
// 處理特定異常
} catch (Exception e) {
// 兜底處理
} finally {
// 必執行清理(關流、釋放鎖)
}
throw:主動拋出異常實例
throws:方法宣告拋出受檢異常,強制呼叫者處理
- 異常傳遞鏈:方法 → 呼叫者 → 呼叫者的呼叫者 … 直到被捕獲或到達執行緒頂層(主執行緒終止 / 事件執行緒進入 UncaughtExceptionHandler)
4. 設計原則與反模式
| 原則 | 說明 |
| 異常不用於流程控制 | 如用 try-catch 替代 if-else 判斷集合是否為空 |
| 具體化異常類別 | 自訂 BusinessException 承載錯誤碼、上下文,避免拋出通用 Exception |
| 保留堆疊追蹤 | 包裝異常時用 throw new CustomException(cause),勿 throw new CustomException(e.getMessage()) |
| 資源用 try-with-resources (Java 7+) | 自動關閉實作 AutoCloseable 的資源 |
| 空 catch 區塊為大忌 | 至少記錄日誌,否則 Bug 隱形 |
5. 專案初期即納入異常策略
定義異常層次結構、日誌規範、重試/熔斷/降級策略、監控告警整合。事後補充成本極高。
- 上一篇文章: Java I/O 體系架構全景:位元組流與字元流雙軌並行設計
- 下一篇文章: JAR 進階應用:應用程式打包與類別庫發布雙軌實戰
Copyright ©
程式碼之家 All Rights Reserved