Java 異常體系核心：受檢異常與非受檢異常的區別、處理策略與面試必考點

Java 異常分為受檢異常與非受檢異常，這一設計直接影響代碼的健壯性與編譯器強制要求。本文梳理異常層級結構、編譯器檢查規則、最佳處理實踐與高頻面試題。

異常層級結構

Throwable
├── Error              // 非受檢：JVM 級嚴重錯誤（OOM、StackOverflow）
└── Exception
    ├── RuntimeException  // 非受檢：編程邏輯錯誤（NPE、索引越界、類轉換）
    └── 其他 Exception    // 受檢：環境/資源問題（IO、SQL、網絡、反射）

核心區別對比

代碼示範：編譯器強制檢查

// 受檢異常：必須處理
public void readFile(String path) throws IOException {
    Files.readAllLines(Paths.get(path)); // 編譯器強制 throws 或 try-catch
}

// 非受檢異常：可不處理
public int parseInt(String s) {
    return Integer.parseInt(s); // NumberFormatException 為 RuntimeException
}

最佳處理策略

受檢異常處理原則

1. 能恢復則捕獲處理：如重試、降級、返回預設值
2. 無法恢復則向上拋出：轉換為業務異常或 RuntimeException
3. 不可吞沒：catch (Exception e) {} 是大忌，至少記錄日誌

非受檢異常預防原則

1. 防禦性編程：參數校驗、空值檢查、邊界判斷
2. 單元測試覆蓋：邊界條件、異常路徑必測
3. 工具類封裝：如 Objects.requireNonNull()、CollectionUtils.isNotEmpty()

經典面試題解析

Q1: 為什麼 Java 設計受檢異常？

強制調用者感知並處理外部依賴失敗風險，提升系統健壯性。但過度使用會導致代碼冗長、異常丟失、棧追蹤污染。

Q2: 如何將受檢異常轉為非受檢？

try {
    riskyOperation();
} catch (IOException e) {
    throw new BusinessException("操作失敗", e); // 包裝為 RuntimeException 子類
}

Q3: Error 能否捕獲處理？

語法上可 catch (Error e)，但極不建議。Error 表示 JVM 不可恢復狀態（如 OOM），捕獲後無法修復，反而掩蓋真實問題。

Effective Java 異常指導原則速查

• 僅對可恢復情況用受檢異常，編程錯誤用運行時異常
• 優先使用標準異常（IllegalArgumentException, IllegalStateException 等）
• 每個拋出的異常必須有 Javadoc @throws 說明
• 保持異常原子性：要么成功要么失敗，不留中間狀態
• 不要在 catch 中忽略異常（至少 log.error）
• 異常不應用於正常控制流（如循環終止）