Java 理論與實踐：平衡測試策略（二）—— 撰寫與優化 FindBugs Bug 偵測器

前言

系列第一篇介紹高效測試策略與撰寫簡單的 System.gc() 偵測器。Bug 模式識別有問題的編碼慣例，常潛伏於 Bug 週邊。雖非所有模式出現處皆為 Bug，但有效偵測器能以較低成本掃描大量程式碼。本文開發更實務的 RuntimeException 捕獲 偵測器（FindBugs 內建）。

RuntimeException 捕獲 Bug 模式

Java 異常階層讓客戶端可分別處理 FileNotFoundException 或統一捕獲 IOException。但易犯錯誤：將多個相同處理邏輯的 catch 區塊合併為單一 catch (Exception e)，因 RuntimeException 繼承 Exception，導致未檢查異常被吞沒而非傳播。

// 錯誤示範：RuntimeException 捕獲
catch (Exception e) { logger.log("...", e); }

// 正確修法：先捕獲 RuntimeException 重拋
catch (RuntimeException e) { throw e; }
catch (Exception e) { logger.log("...", e); }

編譯器不提醒、程式碼審查易疏漏，故需偵測器自動化防禦。

偵測器實作步驟

1. 識別捕獲的異常

繼承 BytecodeScanningDetector，覆寫 visitCode() 初始化收集清單，visit(CodeException) 累積每個 catch 區塊資訊（異常類型、try 區塊位元碼範圍、handler 位置）。

2. 識別拋出的異常

覆寫 sawOpcode() 處理 athrow、invokestatic、invokevirtual、invokespecial 指令：

• athrow：透過 OpcodeStack 取得運算元類型
• 方法呼叫：用 BCEL 查詢方法宣告的已檢查異常

累積方法中各位元碼偏移量拋出的異常類型。

3. 匯總判斷邏輯

visitCode() 返回後，throwList、catchList 已完整。演算法：

1. 迭代捕獲清單，發現捕獲 Exception 的區塊
2. 檢查同位元碼範圍是否有捕獲 RuntimeException 的區塊
3. 檢查 try 區塊範圍內是否拋出 Exception 子類別
4. 若無捕獲 RuntimeException 且 try 區塊未拋出已檢查異常 → 潛在 Bug

優化偵測器：降低誤報率

靜態分析最大成本在處理誤報。優化策略：

• 在 JDK rt.jar、Eclipse、JBoss 等大型碼庫實測
• 消除「try 區塊零拋出已檢查異常」情況（此時捕獲 Exception 可能為刻意設計）
• 建立「信心分數」演算法，動態調整優先級

評分演算法範例

int priority = LOW_PRIORITY + 1;
if (range > 300) priority--;           // try 區塊過大，可信度降低
else if (range < 30) priority++;       // 區塊小，可信度提高
if (catchClauses > 1) priority++;      // 多 catch 合併動機明確
if (thrownSet.size() > 1) priority--;  // 拋出多種已檢查異常，捕獲 Exception 合理
if (caughtException.dead) priority--;  // 死碼區塊

優先級值越低代表嚴重性越高，超過閾值的 Bug 會被忽略。

結語

為 FindBugs 撰寫自訂偵測器能顯著提升程式碼品質。雖開發與優化過程艱辛，但一次投入可長期受惠於所有專案，建立對已知 Bug 模式的自動化防禦網。