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

Question

Иногда я вижу

try {

} catch(Throwable e) {

}

И иногда

try {

} catch(Exception e) {

}

В чем же разница

Answer 1

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

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