突破 Java 異常處理規則：捕獲 Throwable 的必要性與風險實測

核心問題

Java 編譯器強制檢查受檢異常，但 JVM 運行時不保證方法拋出的異常與聲明一致。調用非受信代碼 (外部載入、動態生成、惡意實作) 時，僅捕獲 Exception 會導致 Error 或未聲明的受檢異常逃脫，造成線程死鎖、資源洩漏、安全漏洞。

經典反例：EvilFoo 突破介面契約

介面定義 (無受檢異常)

public interface IFoo {
    void bar(); // 未聲明任何 checked exception
}

看似完整的捕獲代碼

try {
    IFoo foo = ... // 從外部載入實作
    foo.bar();
} catch (RuntimeException e) { /* 處理 */ }
catch (Error e) { /* 處理或重拋 */ }

錯誤假設：編譯器保證 bar() 不拋受檢異常，故無需捕獲 IOException 等。

惡意實作突破防線

public class EvilFoo implements IFoo {
    private Throwable payload;
    public EvilFoo(Throwable t) { this.payload = t; }
    public void bar() { EvilThrow.throwThrowable(payload); }
}

class EvilThrow {
    public static void throwThrowable(Throwable t) throws Throwable { throw t; }
    // 關鍵：編譯後用 BCEL/Jasmin 移除方法簽名中的 throws Throwable
}

運行結果

> java -cp classes Main
Exception in thread "main" java.io.IOException: SURPRISE!
    at Main.main(Main.java:23)
// IOException 逃脫捕獲，主線程崩潰

根本原因分析

1. 編譯期 vs 運行期：受檢異常規則僅在編譯期強制，運行期 JVM 不驗證
2. 字節碼操作：可透過 BCEL、ASM、Javassist 修改字節碼移除 throws 聲明
3. Thread.stop(Throwable)：雖棄用但仍可將任意 Throwable 注入線程
4. 分別編譯：編譯實作時使用聲明拋異常的介面版本，部署時替換為不拋異常版本

正確防禦策略：捕獲 Throwable

try {
    IFoo foo = loadExternalImplementation();
    foo.bar();
} catch (Throwable t) { // 必須捕獲 Throwable
    if (t instanceof Error) {
        // 記錄並決定是否重拋 (如 OutOfMemoryError 應重拋)
        logError(t);
        throw (Error) t;
    }
    // 統一處理 Exception (含受檢與非受檢)
    handleException(t);
}

真實災難案例：SwingUtilities.invokeAndWait() 死鎖

JDK 1.4.1 實作缺陷

public void dispatch() {
    if (catchExceptions) {
        try { runnable.run(); }
        catch (Exception e) { exception = e; } // 只捕獲 Exception！
    } else { runnable.run(); }
    if (notifier != null) {
        synchronized (notifier) { notifier.notifyAll(); } // 異常時不執行！
    }
}

觸發死鎖流程

1. 提交 EvilFoo implements Runnable 至 SwingUtilities.invokeAndWait()
2. run() 拋出 Throwable (非 Exception)
3. dispatch() 的 catch (Exception) 捕獲不到
4. notifier.notifyAll() 永不執行
5. 調用線程在 lock.wait() 永久阻塞 → **EDT 死鎖，GUI 完全凍結**

最佳實踐總結

補充建議

• 使用 @SuppressWarnings("unchecked") 等註解時同樣謹慎，字節碼層面可繞過
• 模組化系統 (OSGi/JPMS) 提供更強隔離，但仍需防禦性編程
• 異常處理原則：捕獲具體、拋出具體、記錄完整、資源必釋