Java: перехват исключения, супертип которого находится в списке бросков

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 немного иначе, чем к другим исключениям, связанным с безопасностью. Мне интересно, есть ли что-то принципиально неправильное в подходе обработки исключений, описанном выше, где у меня есть супертип 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, а не проверенное исключение в целом, но не в этом случаепоскольку он просто добавляет особые случаи поверх особых.