Java 異常體系深度解析：Checked Exception 與 Runtime Exception 的本質區別與選型指南

引言：異常處理的兩條分流

Java 的異常機制是語言的一大特色，但許多開發者僅知 try-catch 語法，卻未深究 受檢異常 與 非受檢異常 的本質差異。本文從類繼承體系、編譯器強制要求、運行時行為、設計意圖四個維度，系統闡述兩者區別，並給出實戰選型建議。

類層級劃分

• Checked Exception：繼承自 java.lang.Exception（但不含 RuntimeException 及其子類）。如 IOException、SQLException、自定義業務異常。
• Runtime Exception：繼承自 java.lang.RuntimeException 或 java.lang.Error。如 NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException。

編譯器強制機制的差異

Checked Exception：強制捕獲或聲明拋出

public void method1() throws CException { // 必須聲明
    throw new CException("Test Exception");
}

// 調用者必須處理
try {
    te.method1();
} catch (CException ce) {
    // 業務恢復邏輯
}

編譯器強制調用者以 try-catch 捕獲或在方法簽名中 throws 繼續拋出，確保異常不被忽視。

Runtime Exception：無強制要求

public void method2(String msg) { // 無需聲明
    if (msg == null) {
        throw new NullPointerException("Message is null");
    }
}

// 調用者可選擇性捕獲，甚至完全不處理
te.method2("Hello"); // 正常
te.method2(null);    // 拋出 NPE，若不捕獲將冒泡至線程終止

編譯器不檢查，屬於「非受檢」，開發者可自行決定是否處理。

傳播行為對比

示例：method3() 調用 method1() 但不捕獲，則必須聲明 throws CException；若調用 method2() 則無此要求。

設計哲學與選型原則

Checked Exception：表達「可預期、可恢復」的業務異常

• 調用者必須知曉並能夠處理的情況：資源不存在、權限不足、數據格式錯誤、外部服務不可用。
• 強制編譯期檢查，避免遺漏處理邏輯，提升系統健壯性。
• 典型場景：文件讀寫、數據庫操作、網絡通訊、業務規則校驗失敗。

Runtime Exception：表達「編程錯誤」或「不可恢復」的系統級故障

• 屬於代碼邏輯缺陷：空指針、數組越界、參數非法、類型轉換失敗。
• 或屬於系統級災難：內存溢出、棧溢出、JVM 錯誤，此時恢復無意義。
• 不強制處理，避免污染業務代碼，讓異常冒泡至頂層統一記錄、告警、降級。

決策流程圖

1. 異常是否因調用者邏輯錯誤導致？→ 是 → Runtime Exception
2. 異常發生後，調用者是否有具體恢復措施？→ 是 → Checked Exception
3. 異常屬於系統級資源耗盡或環境故障？→ 是 → Runtime Exception / Error
4. 其餘情況 → 傾向 Checked Exception，並提供豐富異常信息供診斷。

最佳實踐建議

• 自定義異常體系：建立項目級基類 BizException extends Exception（受檢）與 SysException extends RuntimeException（非受檢），統一錯誤碼、國際化訊息、日誌級別。
• 異常轉換：底層捕獲 SQLException 等受檢異常，轉換為業務受檢異常或系統非受檢異常再拋出，隱藏實現細節。
• 避免濫用 Checked Exception：若調用者只能 log & rethrow，改用 Runtime Exception 減少樣板代碼。
• 文檔化：Javadoc @throws 標籤詳細說明拋出條件與建議處理方式。

總結

Checked Exception 與 Runtime Exception 的核心差異在於編譯器是否強制處理，這映射到異常是否屬於調用者可預期、可控制的業務範疇。合理選型，能讓異常處理成為系統健壯性的基石，而非代碼的負擔。