Исключения в Java

try { throw new IllegalStateException("настоящая ошибка"); }
finally { return "значение из finally"; }
// метод вернул строку, исключение исчезло

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 18, остальные разбираются в тренажёре.

1. #exceptions1 / 5
   Выполнится ли блок finally, если в try есть return?

   A)Нет: return немедленно выходит из метода, и до finally управление уже не доходит

   B)Finally выполнится лишь в том случае, если внутри try действительно возникло исключение, а при обычном return этот блок просто пропускается

   C)Да, finally выполняется при return и при исключении; не выполнится лишь при System.exit или падении JVM

   D)Да, но лишь когда метод возвращает void; при return со значением finally пропускается

   показать ответ и разбор

   +C)Да, finally выполняется при return и при исключении; не выполнится лишь при System.exit или падении JVM

   // разбор: finally выполняется практически всегда: при нормальном завершении try, при return из try (return «придерживается», пока не отработает finally) и при выбросе исключения. Не выполнится он лишь в экстренных случаях: System.exit() (принудительно гасит JVM), фатальный сбой/убийство процесса, бесконечный цикл или демон-поток, чей процесс завершился. Именно поэтому в finally освобождают ресурсы. Отдельная ловушка — return внутри самого finally: он перекрывает результат/исключение из try.

2. #exceptions2 / 5
   Зачем нужен try-with-resources?

   A)Чтобы повторить try при сбое: блок автоматически перезапускается, пока ресурс не откроется

   B)Чтобы ускорить работу с файлами за счёт кэширования открытых потоков между вызовами метода

   C)Чтобы одним блоком catch поймать сразу больше разных типов исключений, не перечисляя их все через вертикальную черту вручную

   D)Чтобы автоматически закрыть ресурсы (AutoCloseable) в обратном порядке даже при исключении — без утечек

   показать ответ и разбор

   +D)Чтобы автоматически закрыть ресурсы (AutoCloseable) в обратном порядке даже при исключении — без утечек

   // разбор: try-with-resources объявляет ресурсы в скобках try(...); каждый должен реализовывать AutoCloseable. По выходу из блока — нормальному ИЛИ через исключение — JVM автоматически вызывает close() для них в порядке, обратном открытию. Это устраняет классические утечки, когда close забыли или он не сработал из-за исключения до finally. Плюс исключение из close не затирает основное — оно добавляется как suppressed. Заметно чище ручного try/finally.

3. #exceptions3 / 5
   Чем отличаются throw и throws?

   A)Throw объявляет прямо в сигнатуре метода, что тот способен бросить исключение, а throws уже фактически выбрасывает его в теле

   B)throw бросает исключение (оператор в теле); throws объявляет в сигнатуре, что метод может его бросить

   C)Throw — для checked-исключений, throws — для unchecked; в остальном они взаимозаменяемы

   D)Это две формы записи одного и того же; какую выбрать — вопрос стиля и версии Java

   показать ответ и разбор

   +B)throw бросает исключение (оператор в теле); throws объявляет в сигнатуре, что метод может его бросить

   // разбор: throw — оператор, который в конкретной точке кода ВЫБРАСЫВАЕТ экземпляр исключения: throw new IllegalArgumentException(...). throws — часть СИГНАТУРЫ метода, объявляющая, какие checked-исключения он может пробросить наружу: void read() throws IOException. То есть throw — действие, throws — контракт. Путать их — классическая оговорка джуна. Для unchecked throws писать не обязательно, но иногда добавляют для документирования.

4. #exceptions4 / 5
   Метод бросает исключение в try, но в finally стоит return. Что вернётся наружу?

   A)Исключение из try сильнее return и прервёт выполнение метода

   B)Значение из return в finally; исключение из try при этом молча проглатывается — это антипаттерн

   C)Оба: сначала метод вернёт значение, а затем повторно выбросит отложенное исключение

   D)Ошибка компиляции: делать return внутри finally, когда в try возможно исключение, прямо запрещено спецификацией самого языка

   показать ответ и разбор

   +B)Значение из return в finally; исключение из try при этом молча проглатывается — это антипаттерн

   // разбор: return (или throw) в finally перекрывает всё, что «недосказал» try: если try выбросил исключение, а finally делает return — наружу уходит именно это значение, а исключение теряется БЕЗ следа (не логируется, не пробрасывается). Компилятор такое разрешает, поэтому баг тихий и коварный — потерянные ошибки крайне трудно ловить. Отсюда правило: не делать return/throw в finally; finally оставляют только под освобождение ресурсов.

5. #exceptions5 / 5
   Чем плох пустой catch: catch (Exception e) {}?

   A)Он ловит слишком мало — Exception не перехватывает RuntimeException, и реальные баги пролетают мимо

   B)Он молча глотает любые исключения, включая ошибки логики (NPE и пр.) — теряется вся диагностика

   C)Пустой catch не компилируется: блок обработки обязан содержать хотя бы логирование или throw

   D)Он замедляет метод, потому что JVM на каждый вызов проверяет, не пуст ли блок обработки

   показать ответ и разбор

   +B)Он молча глотает любые исключения, включая ошибки логики (NPE и пр.) — теряется вся диагностика

   // разбор: catch (Exception e) {} перехватывает почти всё (включая RuntimeException — NPE, IllegalState и т.п.) и НИЧЕГО с этим не делает: ошибка исчезает без лога и без проброса. Программа продолжает работу в некорректном состоянии, а причину потом не найти — это одна из худших практик. Как минимум исключение логируют с контекстом и/или пробрасывают; ловить стоит конкретные типы, а не Exception «на всё». Компилятор пустой catch разрешает, скорость ни при чём.