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异常，但在这种情况下则不然，因为它只是在特殊情况之上添加了特殊情况。