您现在的位置：程式碼之家 >> 編程語言 > >> 更多程式語言 >> 程式設計綜合問答

JDK API 主動檢測未檢查例外設計哲學深度解析

編輯：程式設計綜合問答

核心問題重述

JDK 原始碼中大量出現：

if (pathname == null) {
    throw new NullPointerException();
}

疑問：既然呼叫端應自行檢查，為何 API 仍要重複檢查並拋出例外？這不是多此一舉嗎？

設計哲學：防禦性程式設計與契約式設計

1. API 作為「契約邊界」

前置條件：參數不為 null、數值在合法範圍、狀態有效
後置條件：回傳值符合規範、副作用符合預期
不變條件：物件內部狀態一致性

API 明確檢查前置條件，等同於在程式碼中「文件化」並「強制執行」契約。

2. 早期失敗原則

策略	行為	後果
不檢查	null 傳遞至底層 → 稍後在不相關位置拋出 NPE	堆疊追蹤誤導、除錯困難、錯誤訊息模糊
主動檢查	入口即檢查 → 立即拋出具體例外	錯誤定位精準、訊息清晰、契約違反即時暴露

3. 效能考量：檢查成本極低

單一 if (x == null) 指令級開銷可忽略
JIT 編譯器會內聯、優化熱點路徑
相比「錯誤傳播至深層再處理」的除錯成本，檢查成本微不足道

為何呼叫端檢查不足以取代 API 內部檢查？

場景 1：呼叫端疏忽

// 呼叫端忘記檢查
File file = new File(null); // JDK 內部檢查攔截，拋出 NPE("pathname")

API 檢查成為最後防線，防止無效資料污染系統狀態。

場景 2：呼叫端檢查但邏輯錯誤

// 呼叫端檢查有漏洞
if (path != null && path.length() > 0) { // 忘記 trim()
    File file = new File(path); // 空白字串通過檢查，JDK 再次驗證
}

場景 3：多執行緒競態

// 檢查時非 null，使用時已被其他執行緒設為 null
if (sharedObj != null) {
    // Context switch 發生，sharedObj = null
    sharedObj.doSomething(); // NPE 仍可能發生
}

API 內部檢查在實際使用瞬間驗證，縮小競態視窗。

JDK 7+ 新工具：Objects.requireNonNull()

// JDK 7 引入，標準化空值檢查
public void setPath(String path) {
    this.path = Objects.requireNonNull(path, "path cannot be null");
}

// 更多實用方法
Objects.requireNonNullElse(obj, defaultVal);      // 非空回傳 obj，否則 default
Objects.requireNonNullElseGet(obj, () -> default); // 延遲計算 default
Objects.checkIndex(index, length);                // 索引邊界檢查
Objects.checkFromToIndex(from, to, length);       // 範圍檢查

未檢查例外 vs 已檢查例外：設計決策

💡 核心原則

已檢查例外：呼叫端可合理預期並恢復的情況（IO 錯誤、資料庫連線失敗）
未檢查例外：程式邏輯錯誤、前置條件違反、不可恢復的錯誤（NullPointer、IndexOutOfBounds、IllegalArgument）

JDK API 的 null 檢查拋出 NullPointerException（未檢查），因為傳遞 null 給不接受 null 的參數屬於程式設計錯誤，不應強制呼叫端 try-catch，而應在開發/測試階段修正。

最佳實務總結

API 設計者：公開方法務必驗證前置條件，拋出具體未檢查例外（Objects.requireNonNull、IllegalArgumentException）
呼叫端：不要試圖 catch 未檢查例外來修正邏輯，應修正根本原因
內部私有方法：可視信任邊界決定是否重複檢查（效能敏感路徑可省略）
文件化：使用 @param、@throws、Nullable 註解（@NonNull、@Nullable）明確宣告契約