包裝異常

3.包裝異常

受檢異常在理論上看起來很酷，但在實踐中卻是一個巨大的挫折。

假設你的項目中有一個超級流行的方法。它從您程序中的數百個地方調用。你決定向它添加一個新的檢查異常。很可能這個已檢查的異常真的很重要而且很特別，只有main()方法知道如果它被捕獲時該怎麼做。

這意味著您必須將已檢查的異常添加到throws調用您的超級流行方法的每個方法的子句中。以及在throws調用這些方法的所有方法的子句中。以及調用這些方法的方法。

結果，throws項目中一半方法的子句得到了一個新的檢查異常。當然，您的項目包含在測試中，現在測試無法編譯。現在您還必須在測試中編輯 throws 子句。

然後你的所有代碼（數百個文件中的所有更改）都必須由其他程序員審查。在這一點上，我們問自己為什麼要對項目進行如此多的血腥更改？一天（幾？）的工作和失敗的測試——都是為了添加一個檢查異常？

當然，仍然存在與繼承和方法重寫相關的問題。檢查異常帶來的問題比好處大得多。歸根結底，現在很少有人喜歡它們，也很少有人使用它們。

但是，仍然有很多代碼（包括標準 Java 庫代碼）包含這些已檢查的異常。他們該怎麼辦？我們不能忽視它們，我們也不知道如何處理它們。

Java 程序員建議將已檢查的異常包裝在RuntimeException. 換句話說，捕獲所有已檢查的異常，然後創建未檢查的異常（例如，RuntimeException）並拋出它們。這樣做看起來像這樣：

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

這不是一個非常漂亮的解決方案，但這裡沒有任何犯罪行為：異常只是被塞進了一個RuntimeException.

如果需要，您可以從那裡輕鬆檢索它。例子：

try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}