Java 異常處理的三個層次：好、壞與糟

引言

異常處理是 Java 程式設計的核心議題，幾乎所有入門課程都會涵蓋。然而，許多開發者僅停留在「知道有 try-catch」的層面，缺乏系統性的策略與最佳實務。本文將異常處理品質劃分為三個層次——好（Good）、壞（Bad）、糟（Ugly），並提供具體改善技巧。

好：健全的異常處理架構

編譯器強制的檢查式異常

Java 透過 throws 關鍵字在方法簽名中宣告可能拋出的異常，強制呼叫端處理或繼續拋出。例如 FileInputStream 建構子：

public FileInputStream(String name) throws FileNotFoundException

這種設計將錯誤條件納入方法契約，大幅提升程式碼可靠度與可維護性。

正確的捕獲與處理範例

try {
    FileInputStream fis = new FileInputStream(args[0]);
    // 其他處理邏輯...
} catch (FileNotFoundException fnfe) {
    System.out.println("File: " + args[0] + " not found. Aborting.");
    System.exit(1);
}

進階特性加分項

• 檢查式異常：所有繼承自 Exception（非 RuntimeException）的類別，編譯器強制處理。
• 自訂異常：繼承 Exception 封裝業務邏輯專屬錯誤資訊。
• Java Logging API (JDK 1.4+)：集中化記錄異常堆疊與上下文，利於生產環境除錯。

壞：常見反模式與陷阱

濫用非檢查式異常

繼承 RuntimeException 可繞過編譯器檢查，雖然方便但隱藏錯誤契約。NullPointerException、ArrayStoreException 屬此類。專業團隊應嚴格限制其使用場合。

Catch-all 萬用捕獲器

try {
    // 可能拋出多種檢查式異常的程式碼
} catch (Throwable t) {
    t.printStackTrace(); // 僅印堆疊，未實質處理
}

這種寫法吞沒所有異常，掩蓋真實錯誤，僅適合快速原型或搭配中央錯誤處理器的頂層攔截，嚴禁用於核心業務邏輯。

困難的錯誤恢復策略

記憶體不足（OutOfMemoryError）、寫入失敗、演算法錯誤等嚴重異常，往往難以優雅恢復。常見對策：重試迴路、觸發 GC、通知使用者、優雅降級服務。

糟：語言機制本身的缺陷

拋出異常需分配記憶體的悖論

throw new OutOfMemoryError() 本身需要記憶體分配，在記憶體耗盡時可能導致 JVM 崩潰或無法正確拋出。這是「伺候語言」而非「語言為我所用」的經典案例。

OutOfMemoryError 非檢查式卻常見

OutOfMemoryError 繼承自 Error 而非 Exception，屬非檢查式，但實際上是相當常見的資源耗盡情況。任何記憶體敏感程式都應處理，卻無法透過 throws 宣告強制處理。

缺乏「恢復執行」與「全域異常處理器」機制

• 無法 Resume：C 語言的 setjmp/longjmp 可在處理完異常後返回原呼叫點繼續執行，Java 缺乏對應機制（如假設的 resume 關鍵字）。
• 無全域處理器：C++ 有 set_new_handler() 設定全域記憶體分配失敗處理器，Java 缺乏同等機制，導致 OutOfMemoryError 難以統一攔截。

若您重視這些特性，可至 Java Developer Connection 提交建議。

總結建議

1. 優先使用檢查式異常，設計清晰的異常階層與自訂異常類別。
2. 嚴禁 catch (Throwable) 或 catch (Exception) 不加區分地吞沒錯誤。
3. 針對資源耗盡（OOM）、I/O 失敗等嚴重錯誤，制定專屬恢復/降級策略並整合 Logging API。
4. 關注 Java 版本演進（如 JDK 7 的 try-with-resources、多重 catch、JDK 14 的 Helpful NullPointerExceptions），持續改善異常處理品質。