Java 異常處理深度解析：Checked vs Unchecked 異常的機制與邏輯差異

前言：兩大異常體系的根本分野

Java 將異常分為兩大類：受檢異常 與 非受檢異常。這不僅是語法規則差異，更反映了錯誤處理的兩種哲學：前者代表「可預期且可恢復的業務異常」，後者代表「程式邏輯錯誤或系統級故障」。深入理解兩者機制與適用場景，是編寫健壯 Java 程式的關鍵。

一、機制層面的強制差異

類別繼承體系

classDiagram
    Throwable <|-- Exception
    Throwable <|-- Error
    Exception <|-- RuntimeException
    Exception <|-- IOException
    Exception <|-- SQLException
    Exception <|-- ClassNotFoundException
    RuntimeException <|-- NullPointerException
    RuntimeException <|-- IllegalArgumentException
    RuntimeException <|-- ArrayIndexOutOfBoundsException
    Error <|-- OutOfMemoryError
    Error <|-- StackOverflowError

• Checked Exception：繼承自 `Exception` 但非 `RuntimeException` 子類。編譯器強制要求 `throws` 聲明或 `try-catch` 捕獲。
• Unchecked Exception：繼承自 `RuntimeException` 或 `Error`。編譯器不強制檢查，可選擇性捕獲。

程式碼示範：宣告與傳遞規則

// 自訂受檢異常
class BusinessException extends Exception {
    public BusinessException(String msg) { super(msg); }
}

public class ExceptionFlowDemo {
    
    // 方法 1：拋出受檢異常 → 必須宣告 throws
    public void methodA() throws BusinessException {
        if (Math.random() > 0.5) throw new BusinessException("業務規則違反");
    }
    
    // 方法 2：拋出非受檢異常 → 無需宣告
    public void methodB(String input) {
        if (input == null) throw new IllegalArgumentException("參數不可為 null");
    }
    
    // 方法 3：呼叫 methodA 但不捕獲 → 必須繼續拋出
    public void methodC() throws BusinessException {
        methodA(); // 編譯器強制：要么 catch，要么 throws
    }
    
    public static void main(String[] args) {
        ExceptionFlowDemo demo = new ExceptionFlowDemo();
        
        // 呼叫受檢異常方法 → 必須 try-catch
        try {
            demo.methodA();
            demo.methodC();
        } catch (BusinessException e) {
            System.out.println("捕獲業務異常: " + e.getMessage());
        }
        
        // 呼叫非受檢異常方法 → 可選擇性捕獲
        demo.methodB(null); // 拋出 IllegalArgumentException，若不捕獲將向上傳播至 JVM
    }
}

二、邏輯層面的設計哲學

Checked Exception：預期內的業務異常

核心特徵：呼叫方能夠且應當處理的情況，屬於正常業務流程的一部分。

• 使用者輸入驗證失敗（如 `MalformedURLException`）
• 資源暫時不可用（如 `FileNotFoundException`、`SQLException`）
• 業務規則違反（如餘額不足、庫存不夠）

經典案例：URL 建構器

public class UrlFetcher {
    public String fetchContent(String urlString) {
        try {
            URL url = new URL(urlString); // 拋出 MalformedURLException (Checked)
            // ... 讀取內容
            return "內容";
        } catch (MalformedURLException e) {
            // 呼叫方可處理：提示使用者重新輸入
            return "錯誤：URL 格式無效，請檢查輸入";
        } catch (IOException e) {
            // 網路異常：可重試或記錄日誌
            return "錯誤：網路連線失敗";
        }
    }
}

Unchecked Exception：程式錯誤與系統故障

核心特徵：呼叫方無法在執行期合理恢復的情況，通常源於程式邏輯缺陷或環境極限。

• 程式邏輯錯誤：`NullPointerException`、`IndexOutOfBoundsException`、`IllegalArgumentException`
• 系統資源耗盡：`OutOfMemoryError`、`StackOverflowError`
• API 使用錯誤：未檢查前置條件直接呼叫方法

反面教材：捕獲 RuntimeException 的風險

// ❌ 錯誤做法：掩蓋 Bug
public int calculateAverage(int[] numbers) {
    try {
        int sum = 0;
        for (int i = 0; i <= numbers.length; i++) { // Bug: <= 應為 <
            sum += numbers[i];
        }
        return sum / numbers.length;
    } catch (ArrayIndexOutOfBoundsException e) {
        log.error("計算失敗", e); // 記錄日誌但程式繼續跑，結果錯誤難發現
        return 0;
    }
}

// ✅ 正確做法：修正邏輯，讓異常暴露
public int calculateAverage(int[] numbers) {
    if (numbers == null || numbers.length == 0) {
        throw new IllegalArgumentException("陣列不可為空");
    }
    int sum = 0;
    for (int num : numbers) { // 使用增強 for 迴圈避免索引錯誤
        sum += num;
    }
    return sum / numbers.length;
}

三、實務決策指南：何時選用哪一類？

決策流程圖

graph TD
    A[發生錯誤情況] --> B{呼叫方能否合理處理並恢復?}
    B -->|是| C[Checked Exception]
    B -->|否| D{是否為程式邏輯錯誤?}
    D -->|是| E[Unchecked Exception - RuntimeException]
    D -->|否| F{是否為系統級災難性故障?}
    F -->|是| G[Error]
    F -->|否| H[重新評估設計]

最佳實務原則

四、進階主題：異常鏈與包裝策略

標準異常包裝模式

public class ServiceException extends RuntimeException {
    private final String errorCode;
    
    public ServiceException(String errorCode, String message, Throwable cause) {
        super(message, cause); // 關鍵：保留原始原因
        this.errorCode = errorCode;
    }
    
    public String getErrorCode() { return errorCode; }
}

// 使用範例
public User findUserById(Long id) {
    try {
        return jdbcTemplate.queryForObject("SELECT * FROM users WHERE id=?", 
            new UserRowMapper(), id);
    } catch (EmptyResultDataAccessException e) {
        throw new ServiceException("USER_NOT_FOUND", "使用者不存在: " + id, e);
    } catch (DataAccessException e) {
        throw new ServiceException("DB_ERROR", "資料庫存取失敗", e);
    }
}

Java 17+ 模式匹配簡化捕獲

// Java 17+ 型別模式匹配
try {
    riskyOperation();
} catch (IOException | SQLException e) { // 多重捕獲
    log.error("資源存取失敗", e);
    throw new ServiceException("IO_ERROR", "儲存層異常", e);
} catch (RuntimeException e) { // 最後兜底
    log.error("未預期邏輯錯誤", e);
    throw e; // 重新拋出，讓全域異常處理器接管
}

總結

Java 異常機制的雙軌制設計，本質上是將「業務流程的可預期分支」與「程式缺陷的不可預期終止」分離。優秀的異常設計應做到：

1. Checked 異常：僅用於呼叫方必須感知且能處理的業務情境，並納入方法契約。
2. Unchecked 異常：用於程式 Bug、前置條件違反、系統級故障，不應被常規捕獲掩蓋，而應透過測試、靜態分析、Code Review 在開發階段消除。
3. 包裝轉換：在架構邊界（Controller、Service、Repository）將底層 Checked 異常包裝為語義清晰的 Unchecked 異常，保留完整堆疊追蹤。

記住：異常是給開發者看的，錯誤訊息是給使用者看的。兩者分離處理，才能兼顧系統穩健與使用者體驗。