Разница между использованием Throwable и Exception в пробном улове

Question

иногда вижу

try {

} catch(Throwable e) {

}

А иногда

try {

} catch(Exception e) {

}

В чем разница

Answer 1

Перехватывая Throwable, он включает в себя вещи, которые подкласс Error. Как правило, вы не должны этого делать, за исключением, возможно, самого высокого уровня «catch all» потока, где вы хотите регистрировать или иным образом обрабатывать абсолютно все, что может пойти не так. Это было бы более типично в приложении типа платформы (например, на сервере приложений или в среде тестирования), где оно может запускать неизвестный код, и на него не должно воздействовать что-либо , которое идет не так с этим кодом, насколько насколько это возможно.

Answer 2

Первый перехватывает все подклассы Throwable (включая Exception и Error), второй перехватывает все подклассы Exception.

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

Answer 3

Throwable - это суперкласс Exception, а также Error. В обычных случаях мы всегда должны ловить подклассы Exception, чтобы основная причина не терялась.

Только в особых случаях, когда вы видите вероятность того, что что-то пойдет не так, что не контролирует ваш Java-код, вы должны ловить Error или Throwable.

Я помню, как ловил Throwable, чтобы указать, что нативная библиотека не загружена.

Answer 4

Thowable действительно перехватывает все, даже ThreadDeath, который по умолчанию генерируется, чтобы остановить поток из устаревшего Thread.stop() метода. Таким образом, поймав Throwable, вы можете быть уверены, что никогда не покинете блок try, по крайней мере, не пройдя через блок catch, но вы должны быть готовы обрабатывать OutOfMemoryError и InternalError или StackOverflowError.

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