模板
教程
環境
性能
功能
管理
Java 理論與實踐: 平衡測試，第 2 部分
這一簡短系列的 第 1 部分 介紹了如何進行有效測試，它構建了 FindBugs 插件來查找一個簡單的 bug 模式（只需調用 System.gc() 即可）。Bug 模式會標識有問題的編碼實踐，它們常常位于 bug 所在的區域。當然，并不是所有出現 bug 模式的地方都一定出現 bug，但這并不能抹殺 bug 模式檢測器的巨大作用。一個有效 bug 模式檢測器的主要功能是發現更高百分比的可疑代碼，使該模式具有更大的使用價值。創建 bug 模式檢測器可以提高使用價值；創建檢測器之后，無論是現在還是將來，您都可以在您需要的任何代碼上運行它，并且您可能對發現的問題感到驚訝。例如，第 1 部分 中的簡單檢測器顯示了對 System.gc() 的調用，在 JDK 1.4.2 中，它隱藏在 JPEG 圖像 I/O 庫中。
編寫檢測器可以查找對特定靜態方法的調用，這并不困難，但是大多數的 bug 檢測器都包含相當多的分析和實現。在這一期的文章中，您將開發一個稱為 RuntimeException capture 的更小 bug 模式的檢測器（目前，FindBugs 發行版中已包含此 bug 檢測器。）
用 Java™ 語言進行異常處理的一個優點是：異常是一些對象，try-catch 機制了解異常類型的分層結構，并在客戶機如何處理錯誤處理方面提供實際靈活性。例如，如果不能找到文件，則 FileInputStream 構造函數會拋出 FileNotFoundException，該異常是 IOException 的一個子類。此傳統用法允許客戶機處理未發現文件的條件，這些條件是從其他與文件相關的條件中分離出來的（如果他們喜歡單獨捕獲 FileNotFoundException）。但是，他們還可以使用捕獲 IOException 的方法處理所有與文件相關的錯誤條件。
另一方面，異常處理的主要缺陷是：在正確使用異常時，易于建立帶有三行或四行業務邏輯以及 20 或 30 行異常處理的方法。因為錯誤恢復代碼在測試時容易出現錯誤并且執行困難，使一部分專門用于異常處理的代碼無所適從并容易出錯。這種情況的典型示例如清單所示，其中帶有兩行 “真的” 代碼的方法需要三個獨立的捕獲塊，每個捕獲塊都執行完全相同的操作 —— 記錄該異常：
清單 1. 多個相同的捕獲塊
public void addInstance(String className) {
try {
Class clazz = Class.forName(className);
objectSet.add(clazz.newInstance());
}
catch (IllegalAclearcase/" target="_blank" >ccessException e) {
logger.log("Exception in addInstance", e);
}
catch (InstantiationException e) {
logger.log("Exception in addInstance", e);
}
catch (ClassNotFoundException e) {
logger.log("Exception in addInstance", e);
}
}
|
請參見清單 1，您可能嘗試將三個捕獲塊合并成捕獲 Exception 的單獨捕獲塊，因為每個捕獲塊的捕獲恢復操作是相同的。乍一看，該策略似乎是一個好方法 —— 但代碼副本有錯誤，所以整合這些復制路徑應該是一種改進。不過，此 “改進” 常常會帶來意想不到的結果。因為 RuntimeException 擴展了 Exception，將三個捕獲塊合并成一個捕獲塊（如清單 2 所示），所以這會更改語義，現在，未經檢查的異常將被記錄（而不傳播）。此 bug 模式（其中 RuntimeException 容易被超大捕獲塊捕獲）也稱為 RuntimeException 捕獲。
