1. Обзор
В этом уроке мы рассмотрим последствия ловли Бросаемый .
2. Бросаемый класс
В документации Java класс Throwable определяется как ” суперкласс всех ошибок и исключений в языке Java “.
Давайте посмотрим на иерархию класса Throwable :
Класс Throwable имеет два прямых подкласса, а именно классы Error и Exception .
Error и его подклассы являются непроверенными исключениями, в то время как подклассы Exception могут быть либо проверенными, либо непроверенными исключениями .
Давайте рассмотрим типы ситуаций, с которыми может столкнуться программа, когда она терпит неудачу.
3. Восстанавливаемые Ситуации
Существуют ситуации, когда восстановление, как правило, возможно и может быть обработано с помощью проверенных или непроверенных подклассов класса Exception .
Например, программа может захотеть использовать файл, который не существует в указанном месте, в результате чего будет выдано исключение FileNotFoundException .
Другим примером является программа, пытающаяся получить доступ к системному ресурсу без разрешения на это, в результате чего возникает непроверенное AccessControl Исключение .
Согласно документации Java, класс Exception “указывает условия, которые разумное приложение может захотеть перехватить “.
4. Безвозвратные Ситуации
Бывают случаи, когда программа может попасть в состояние, когда восстановление невозможно в случае сбоя. Распространенными примерами этого являются случаи переполнения стека или нехватки памяти в JVM.
В этих ситуациях JVM выдает StackOverflowError и OutOfMemoryError соответственно. Как следует из их названий, это подклассы класса Error .
Согласно документации Java, класс Error “указывает на серьезные проблемы, которые разумное приложение не должно пытаться поймать “.
5. Пример Восстанавливаемых и Безвозвратных ситуаций
Предположим, что у нас есть API, который позволяет вызывающим абонентам добавлять уникальные идентификаторы в какое-либо хранилище с помощью метода addIDsToStorage :
class StorageAPI {
public void addIDsToStorage(int capacity, Set storage) throws CapacityException {
if (capacity < 1) {
throw new CapacityException("Capacity of less than 1 is not allowed");
}
int count = 0;
while (count < capacity) {
storage.add(UUID.randomUUID().toString());
count++;
}
}
// other methods go here ...
} При вызове добавить идентификаторы в хранилище может возникнуть несколько потенциальных точек сбоя :
- CapacityException – Проверяемый подкласс Исключения при передаче емкости значения менее 1
- NullPointerException – Непроверенный подкласс Исключения , если вместо экземпляра Setпредоставляется нулевое хранилище значение
- OutOfMemoryError – Непроверенный подкласс Error , если у JVM заканчивается память перед выходом из цикла while
Ситуации Capacity Exception и NullPointerException – это сбои, от которых программа может восстановиться, но ошибка OutOfMemoryError является неисправимой.
6. Ловить Бросаемые
Предположим, что пользователь API только поймал Throwable в try-catch при вызове добавить идентификаторы в хранилище :
public void add(StorageAPI api, int capacity, Setstorage) { try { api.addIDsToStorage(capacity, storage); } catch (Throwable throwable) { // do something here } }
Это означает, что вызывающий код реагирует на восстанавливаемые и безвозвратные ситуации одинаково.
Общее правило при обработке исключений заключается в том, что блок try-catch должен быть как можно более конкретным при перехвате исключений. То есть/| следует избегать сценария “все включено” .
Ловить Throwable в нашем случае нарушает это общее правило. Чтобы реагировать на восстанавливаемые и безвозвратные ситуации по отдельности, вызывающий код должен был бы проверить экземпляр объекта Throwable внутри блока catch .
Лучшим способом было бы использовать конкретный подход к обработке исключений и избегать попыток справиться с непоправимыми ситуациями .
7. Заключение
В этой статье мы рассмотрели последствия ловли Бросаемый в try-catch блок.
Как всегда, полный исходный код примера доступен на Github .