Java assert 斷言完整指南：語法、陷阱、最佳實踐與替代方案

assert 關鍵字自 JDK 1.4 引入，用於開發階段的假設檢查。本文系統梳理語法、運行機制、四大陷阱、適用場景與現代替代方案。

語法與運行機制

// 形式一：簡單斷言
assert booleanExpression;

// 形式二：帶訊息斷言
assert booleanExpression : "錯誤訊息表達式";

• 表達式為 true：程式繼續執行
• 表達式為 false：拋出 AssertionError（第二形式附帶訊息）
• 預設關閉：JVM 啟動需加 -ea 或 -enableassertions 啟用
• IDE 專案運行配置中需手動勾選「Enable assertions」

四大核心陷阱

1. 運行時需顯式啟動：生產環境通常關閉，斷言失效等同無代碼。Web 容器部署更難控制 JVM 參數。
2. 誤用於業務流程控制：assert 為測試/調試設計，若用於業務邏輯（如參數校驗），關閉後邏輯缺失導致 Bug 隱匿。
3. 失敗直接終止程式：拋出 Error 而非 Exception，無法被常規 catch 捕獲，生產環境不可接受。
4. 副作用風險：斷言表達式中包含狀態修改（如 assert list.remove(x)），關閉後副作用消失，行為不一致。

適用場景（狹窄但重要）

• 框架/基礎設施代碼：檢查內部不變量（如資料結構完整性、演算法前置條件）
• 契約式設計：方法入口檢查 precondition，出口檢查 postcondition
• 單元測試輔助：測試代碼中啟用 -ea，作為輕量級斷言（JUnit assertTrue 更豐富）
• 不可恢復的內部錯誤：理論上不可能發生的分支（default: in switch on enum）

代碼範例：正確用法

public static List<Integer> quickSort(List<Integer> list) {
    assert list != null : "輸入列表不能為 null"; // 文檔化前置條件
    // 分配臨時空間...
    for (int i : list) { /* 排序邏輯 */ }
    assert isSorted(list) : "排序後列表應有序"; // 文檔化後置條件
    return list;
}

現代替代方案對比

專家建議總結

1. 業務代碼禁用 assert：改用 Objects.requireNonNull、if-check-throw、Validation 框架
2. 核心庫可慎用：僅檢查「理論上不可能違反」的內部不變量，且確保測試環境啟用 -ea
3. 永不在 assert 中放副作用：表達式必須純粹無副作用
4. 優先選擇 JUnit/AssertJ：測試階段斷言功能完備，無需自建機制
5. 文檔化意圖：即使關閉，assert 仍作為可執行文檔說明代碼契約

「斷言是給程式設計師看的文檔，不是給用戶看的錯誤處理。」 —— 《Effective Java》