Обертывание контролируемой исключительной ситуации в исключение непроверенное в Java?
Я проверил поддержку Azur, и они отметили, что не все методы, предоставляемые Hadoop, реализованы. Так что в моем случае LISTSTATUS_BATCH не имеет значения.
4 ответа
RuntimeException должен использоваться только, когда клиент не может восстановиться с того, что проблема. Иногда уместно сделать то, о чем Вы говорите, но чаще это не является соответствующим.
при использовании JDK> = 1.4, затем можно сделать что-то как:
try {
// Code that might throw an exception
} catch (IOException e) {
throw new RuntimeException(e);
} catch (ClassNotFoundException e) {
throw new RuntimeException(e);
}
и повторно брошенный RuntimeException будут включать исходную причину в нем. Таким образом, кто-то во главе потока, ловя RuntimeException - Ваши потоки ловят RuntimeException, таким образом, они не просто тихо умирают, правильно? - может, по крайней мере, распечатать ПОЛНОЕ отслеживание стека причины.
, Но поскольку другие сказали и скажут, исключения проверяются по причине. Только сделайте это, когда Вы положительны, что Ваши клиенты не могут восстановиться с проблемы, которую Вы повторно бросаете как исключение непроверенное.
ПРИМЕЧАНИЕ: Лучше, чем всего RuntimeException должен был бы использовать более определенное исключение непроверенное, если Вы доступны. Например, если единственная причина, которую Ваш метод мог бы бросить ClassNotFoundException, состоит в том, потому что конфигурационный файл отсутствует, Вы могли повторно бросить MissingResourceException, который является исключением непроверенным, но дает больше информации о том, почему Вы бросаете его. Другая польза RuntimeException с, чтобы использовать, если они описывают проблему, которую Вы повторно бросаете, IllegalStateException, TypeNotPresentException и UnsupportedOperationException.
Также примечание, что это всегда - хорошая идея для Ваших потоков для ловли RuntimeException и в минимальном журнале это. По крайней мере, этот способ, которым Вы понимаете, почему Ваши потоки уходят.
Две точки относительно лучших практик обработки исключений:
- код Вызывающей стороны не может сделать, что-либо об исключении-> Делает его неконтролируемое исключение
- , код Вызывающей стороны примет некоторые полезные меры восстановления на основе информации в исключении->, Делают его контролируемая исключительная ситуация
, И можно бросить RuntimeException с или без внутреннего исключения, в зависимости от того, что вызывающая сторона может сделать с ним. Если Вы не повторно бросаете внутреннее исключение затем, необходимо зарегистрировать его в методе, если важный.
Вы делаете его корректный путь.
, Чтобы позволить контролируемым исключительным ситуациям передать, хотя без того, чтобы быть проверенным, необходимо перенести их в исключения непроверенные.
Просто помнят, Исключения проверяются по причине.
Если Вы хотите избежать слишком многих try - catch es, поймайте обоих исключения на самой фабрике и обработайте их там. Возможно, возвратите реализацию по умолчанию.
Вы имеете для обрабатывания исключений, здесь или где-то в другом месте.
И так как это - фабрика, я думаю, что лучше, что эти исключения обработаны на самой фабрике (тот же метод или другой метод), и возврат реализации по умолчанию.
Так или иначе, (бизнес-функция) у вызывающей стороны не будет подсказки о том, что должно быть сделано, когда она встречается ClassNotFoundException.