Java 異常處理特殊情況深度解析：邊界條件與最佳實踐

特殊情況一：finally 中的 return 吞噬異常

public String test() {
    try {
        throw new RuntimeException("原始異常");
    } finally {
        return "finally 返回值"; // 吞噬異常，調用者感知不到異常！
    }
}
// 調用 test() 正常返回 "finally 返回值"，異常丟失

鐵律：finally 中絕不使用 return、throw、break、continue 控制流程語句。

特殊情況二：try-with-resources 中 close() 異常抑制

class Resource implements AutoCloseable {
    @Override public void close() throws Exception {
        throw new Exception("關閉失敗");
    }
}

try (Resource r = new Resource()) {
    throw new Exception("業務異常");
} catch (Exception e) {
    // e = 業務異常
    // e.getSuppressed() = [關閉失敗異常]
    System.out.println("主異常: " + e.getMessage());
    for (Throwable s : e.getSuppressed()) {
        System.out.println("被抑制: " + s.getMessage());
    }
}

優勢：主異常不被掩蓋，關閉異常不丟失，通過 getSuppressed() 可訪問。

特殊情況三：異常鏈與原因追蹤

try {
    // 底層操作
} catch (SQLException e) {
    // 包裝為業務異常，保留原始原因
    throw new BusinessException("用戶保存失敗", e); // 构造器傳入 cause
}

// 異常鏈打印
e.printStackTrace(); // 自動打印完整鏈路
// 或手動遍歷
Throwable cause = e;
while (cause != null) {
    System.out.println(cause.getClass() + ": " + cause.getMessage());
    cause = cause.getCause();
}

特殊情況四：多線程異常處理

// 線程池任務異常捕獲
ExecutorService executor = Executors.newFixedThreadPool(2);
Future future = executor.submit(() -> {
    throw new RuntimeException("任務異常");
});

try {
    future.get(); // 這裡會拋出 ExecutionException，cause 是原始異常
} catch (ExecutionException e) {
    Throwable realCause = e.getCause(); // 獲取真實異常
    log.error("任務失敗", realCause);
}

// 全局異常處理器
Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
    log.error("線程 {} 未捕獲異常: ", thread.getName(), throwable);
});

特殊情況五：序列化/反序列化異常

// 異常類實現 Serializable 才能跨 JVM 傳輸
public class BizException extends Exception implements Serializable {
    private static final long serialVersionUID = 1L; // 必須顯式聲明
    // 否則反序列化時可能 InvalidClassException
}

特殊情況六：類初始化異常 (ExceptionInInitializerError)

public class Config {
    static {
        // 靜態塊拋異常 → 包裝為 ExceptionInInitializerError
        loadConfig(); // 可能拋 IOException
    }
}

// 使用時
try {
    Config.class.getDeclaredField("x");
} catch (ExceptionInInitializerError e) {
    Throwable root = e.getCause(); // 獲取真實原因 (IOException)
}

特殊情況七：棧溢出與堆溢出 (Error 而非 Exception)

• StackOverflowError：遞歸過深、循環調用，不可捕獲恢復，需修正算法
• OutOfMemoryError：堆/元空間耗盡，極難恢復，可嘗試釋放緩存後重試關鍵操作
• 兩者繼承自 Error，不屬於受檢異常，通常不應捕獲

特殊情況八：斷言錯誤 (AssertionError)

// -ea 啟用斷言
assert condition : "錯誤信息";
// 失敗拋 AssertionError，屬於 Error，生產環境建議關閉斷言

最佳實踐總結表

生產級異常處理檢查清單

• [ ] 所有資源使用 try-with-resources
• [ ] 異常包裝保留完整因果鏈
• [ ] 業務異常繼承 RuntimeException (非受檢)
• [ ] 系統/框架異常轉換為業務異常上拋
• [ ] 統一異常處理切面 (AOP) 記錄日誌、返回統一錯誤碼
• [ ] 關鍵業務路徑異常告警配置
• [ ] 異常信息不洩露敏感數據 (SQL、堆棧、用戶隱私)
• [ ] serialVersionUID 顯式聲明

精通異常處理邊界條件，是編寫穩健、可診斷、可維護 Java 系統的關鍵能力。