Как обернуть проверенные исключения, но сохранить исходные исключения времени выполнения в Java

Я использую «слепой» повторный вызов, чтобы пропустить проверенные исключения. Я использовал это для прохождения через Streams API, где я не могу использовать лямбда-выражения, которые выдают проверенные исключения. например, у нас есть функциональные интерфейсы ThrowingXxxxx, поэтому проверенное исключение может быть пропущено.

Это позволяет мне естественным образом перехватывать проверенное исключение в вызывающем объекте, не зная, что вызываемый объект должен передать его через интерфейс, который не допускает проверенных исключений.

try {
  // some code that can throw both checked and runtime exception

} catch (Exception e) {
  throw rethrow(e);
}

В вызывающем методе я могу снова объявить проверенное исключение.

public void loadFile(String file) throws IOException {
   // call method with rethrow
}

/**
 * Cast a CheckedException as an unchecked one.
 *
 * @param throwable to cast
 * @param <T>       the type of the Throwable
 * @return this method will never return a Throwable instance, it will just throw it.
 * @throws T the throwable as an unchecked throwable
 */
@SuppressWarnings("unchecked")
public static <T extends Throwable> RuntimeException rethrow(Throwable throwable) throws T {
    throw (T) throwable; // rely on vacuous cast
}

Существует множество различных вариантов обработки исключений. Мы используем некоторые из них.

https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html

Throwables.propagate() делает именно это:

try {
    // some code that can throw both checked and runtime exception
} catch (Exception e) {
    throw Throwables.propagate(e);
}

ОБНОВЛЕНИЕ: этот метод устарел. Подробнее см. на этой странице.

Не совсем.

Если вы делаете это часто, вы можете спрятать его во вспомогательный метод.

static RuntimeException unchecked(Throwable t){
    if (t instanceof RuntimeException){
      return (RuntimeException) t;
    } else if (t instanceof Error) { // if you don't want to wrap those
      throw (Error) t;
    } else {
      return new RuntimeException(t);
    }
}

try{
 // ..
}
catch (Exception e){
   throw unchecked(e);
}

У меня есть специально скомпилированный файл .class, содержащий следующее:

public class Thrower {
    public static void Throw(java.lang.Throwable t) {
        throw t;
    }
}

Это просто работает. Компилятор Java обычно отказывается компилировать это, но верификатору байт-кода все равно.

Класс используется аналогично ответу Питера Лоури:

try {
  // some code that can throw both checked and runtime exception

} catch (Exception e) {
    Thrower.Throw(e);
}

Вы можете переписать то же самое, используя оператор instanceof

try {
    // some code that can throw both checked and runtime exception
} catch (Exception e) {
    if (e instanceof RuntimeException) {
        throw e;
    } else {
        throw new RuntimeException(e);
    }
}

Однако ваше решение выглядит лучше.

Проблема в том, что Exception слишком широкое. Вы должны точно знать, каковы возможные проверенные исключения.

try {
    // code that throws checked and unchecked exceptions
} catch (IOException | SomeOtherException ex) {
    throw new RuntimeException(ex);
}

Причины, по которым это не сработает, раскрывают более глубокие проблемы, которые следует решать вместо этого:

Если метод объявляет, что он throws Exception, то он слишком широк. Знание того, что «что-то может пойти не так», без дополнительной информации бесполезно для вызывающего абонента. Метод должен использовать определенные классы исключений в значимой иерархии или использовать непроверенные исключения, если это необходимо.

Если метод выдает слишком много различных типов проверенных исключений, то он слишком сложен. В зависимости от ситуации его следует либо преобразовать в несколько более простых методов, либо исключения должны быть расположены в разумной иерархии наследования.

Конечно, могут быть исключения из правил. Объявление метода throws Exception может быть вполне разумным, если он используется какой-то сквозной структурой (например, JUnit, AspectJ или Spring), а не содержит API для использования другими.

Обычно я использую один и тот же тип структуры кода, но сокращаю ее до одной строки в одном из немногих случаев, когда тернарный оператор действительно делает код лучше:

try {
  // code that can throw
}
catch (Exception e) {
  throw (e instanceof RuntimeException) ? (RuntimeException) e : new RuntimeException(e);
}

Это не требует дополнительных методов или блоков catch, поэтому мне это нравится.