Java 異常體系深度解析：Checked vs Runtime Exception

機制層面差異

程式碼示例

public class ExceptionDemo {
    // Checked Exception：必須宣告
    public void readFile(String path) throws IOException {
        Files.readAllLines(Paths.get(path));
    }

    // Runtime Exception：無需宣告
    public void parseInt(String s) {
        Integer.parseInt(s); // 可能拋 NumberFormatException
    }

    // 傳遞 Checked Exception
    public void processFile(String path) throws IOException {
        readFile(path); // 未捕獲，向上拋出
    }
}

調用端：

public static void main(String[] args) {
    ExceptionDemo demo = new ExceptionDemo();

    // 必須處理 Checked Exception
    try {
        demo.readFile("data.txt");
    } catch (IOException e) {
        e.printStackTrace();
    }

    // Runtime Exception 可不捕獲
    demo.parseInt("abc"); // 運行時拋出 NumberFormatException
}

邏輯層面：何時使用哪一種？

Checked Exception —— 可預期、可恢復的業務異常

• 調用方能夠且應該處理的情況。
• 例：MalformedURLException —— 用戶輸入錯誤 URL，程式可提示重輸。
• 強制捕獲機制確保開發者正視並處理這類情境。

Runtime Exception —— 程式邏輯錯誤、不可恢復的缺陷

• 調用方無法在運行時修正的 Bug。
• 例：ArrayIndexOutOfBoundsException —— 索引越界屬編碼錯誤，須修正代碼而非捕獲。
• 捕獲它會掩蓋 Bug，導致測試階段難以發現（堆疊追蹤才是最佳定位工具）。

最佳實踐原則

1. 別捕獲 RuntimeException 除非在頂層框架統一記錄日誌並友好提示用戶。
2. Checked Exception 應盡早轉換：在 Service 層捕獲並包裝為業務異常（自定義 Checked Exception），避免將底層實現細節（如 SQLException）外洩到 Controller。
3. 文檔化異常契約：Javadoc @throws 明確說明拋出條件與含義。
4. 避免「吞掉」異常：catch (Exception e) {} 是大忌，至少記錄日誌。

總結

Checked Exception 強制建立「異常契約」，適合可預期業務流程；Runtime Exception 守護程式正確性，暴露編碼缺陷。善用兩者分工，才能構建健壯、可維護的 Java 系統。