Java 異常規範（throws 子句）完整指南：編譯期強制檢查與設計最佳實務

Java 獨特的 異常規範 機制（throws 子句）強制方法宣告可能拋出的已檢查異常，讓編譯器在建構期就能驗證異常處理的完整性。這比 C++ 的執行期檢查更早發現問題。本文將詳細說明語法規則、編譯器強制邏輯、RuntimeException 的特例，以及實務上的設計考量。

基本語法：throws 關鍵字

方法宣告中，參數列表之後、方法主體之前，以 throws 列出可能拋出的已檢查異常：

void f() throws TooBigException, TooSmallException, DivZeroException {
    // 方法本體
}

• 僅需列出已檢查異常（繼承 Exception 但非 RuntimeException）
• 多個異常以逗號分隔，順序無關緊要
• 若方法不拋出任何已檢查異常，可省略 throws 子句

編譯器強制檢查機制

Java 採取「處理或宣告」原則：

1. 若方法內部拋出已檢查異常（throw new IOException()）且未以 try-catch 捕獲，必須在方法簽名加上 throws IOException
2. 呼叫該方法的程式碼，同樣面臨「捕獲或再宣告」的選擇
3. 這形成一條從底層到 main() 的異常傳遞鏈，編譯器逐層驗證

這是相較 C++ 最大的優勢：C++ 異常規範違反只在執行期發現，Java 則在編譯期攔截。

RuntimeException 的特殊地位

RuntimeException 及其子類不需出現在 throws 子句中，原因有二：

• 它們代表程式邏輯錯誤，幾乎發生於任何程式碼路徑，若強制宣告將汙染所有方法簽名
• Java 語言規範假定執行環境會自動處理（印堆疊並終止執行緒），開發者應專注於修正 Bug 而非捕獲它們

但你仍可選擇在 throws 中列出 RuntimeException 以文件化意圖，編譯器允許但不強制。

「欺騙」編譯器：宣告未實際拋出的異常

你可以在 throws 列出方法實際上不會拋出的異常：

void f() throws IOException {  // 實際上不拋 IOException
    // ...
}

編譯器會信任宣告，強制呼叫端處理 IOException。這在介面設計時可作為預留擴充點（佔位符），未來實作加入 I/O 操作時無需修改介面簽名。但濫用會誤導呼叫端，建議謹慎使用並附註 JavaDoc 說明。

介面與覆寫的異常規範規則

• 介面方法宣告的 throws，實作類可省略或縮減（拋出較少或較具體的異常），但不可擴大（新增父介面未宣告的已檢查異常）
• 覆寫父類方法時，同樣遵循「異常類型共變」：子類方法拋出的已檢查異常必須是父類方法宣告異常的子類型

實務設計建議

總結

throws 子句是 Java 靜態類型系統延伸到錯誤處理的關鍵機制。它強制開發者在設計階段就思考異常流向，雖增加些許撰寫負擔，卻大幅降低生產環境因遺漏處理而導致的非預期崩潰。善用編譯器這道防線，是寫出健壯 Java 程式的基石。