Java：捕獲異常，其異常類型在throws列表中

Question

我偶爾會以以下方式編寫Java代碼：

public static TrustManager[] getTrustManagers(TruststoreParams tsParams)
throws IOException, GeneralSecurityException {
    TrustManagerFactory tmf = null;
    FileInputStream fis = null;
    try {
        ...
        return tmf.getTrustManagers();
    }
    catch (NoSuchAlgorithmException nsae) {
        throw new RuntimeException(nsae);
    }
    finally {
        ...
    }

在這里，我對待NoSuchAlgorithmException的方式與其他與安全性有關的異常有所不同。 我想知道上面的異常處理方法是否存在根本錯誤，在異常處理方法中，我在throws列表中具有GeneralSecurityException超級類型，但是我專門捕獲並處理其子類型之一，並將其​​包裝為RuntimeException 。

如果與我上面設置的方法不同，您將如何重寫上述方法框架，為什么？

Answer 1

在我看來，這很合理。 通過拋出RuntimeException，您實際上將這種情況視為致命錯誤，如果您的應用程序要求您使用特定算法，這將是有意義的。

Answer 2

捕獲比拋出更具體的異常是有意義的，因為如果您有特定的響應，則對特定情況做出響應總是好的。 但是，在這種情況下，為什么將其包裝在RuntimeException呢？ 是否比GeneralSecurityException更糟糕的情況呢？也就是說，它太糟糕了，您想繞過調用者的常規處理？ 一個不同的GeneralSecurityException會不會那么糟糕？

這些年來，我的方法已經改變。 最近，我聲明了很少的異常，通常只是調用者可以通過編程處理的異常，大多數與業務相關（例如NoSuchUser ）。 “系統”或基礎結構問題被放入各種RuntimeException中，因為調用者實際上除了救助外別無選擇。

在您的情況下，調用者可以使用IOException或GeneralSecurityException做任何事情嗎？ 如果不是這樣，我根本不會將它們放在簽名中（它只會使調用者感到困惑），而只包裝RuntimeException中發生的所有異常。

Answer 3

我認為，如果以上方法之一對NoSuchAlgorithmException感興趣，那么它應該在沒有進一步幫助的情況下進行處理。

我會做類似的事情

 try {
     ...
     trustManager.getTrustmanagers(...);

 } catch (GeneralSecurityException e) {
     if (e instanceof NoSuchAlgorithmException) {
        // do something special 
     } else {
        // do regular error handling
     }
 }

在這種情況下，不需要創建多余的結構來觸發遠距離的動作，當我偶然發現它們時，我總是感到困惑。

我必須承認，一般來說我更喜歡RuntimeExceptions而不是Checked異常，但在這種情況下則不然，因為它只是在特殊情況之上添加了特殊情況。