Краткий ответ

catch(Throwable) перехватывает не только обычные исключения, но и экземпляры Error, включая потенциально невосстанавливаемые ошибки виртуальной машины. Поэтому такой обработчик может скрыть критический сбой, продолжить работу в повреждённом состоянии или помешать штатному завершению потока. Для обычной бизнес-логики следует перехватывать Exception, а Throwable допустимо рассматривать только на тщательно выбранной границе приложения, обычно для журналирования и повторного выброса.

Исторический контекст

Корневой тип Throwable объединяет два крупных направления иерархии: Exception для условий, которые приложение может обработать, и Error для серьёзных проблем среды выполнения или состояния программы. Такое разделение позволяет не заставлять каждый метод обрабатывать критические сбои вроде нехватки памяти.

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

Постановка проблемы

Если общий обработчик перехватит OutOfMemoryError, StackOverflowError, LinkageError или ThreadDeath, он может ошибочно трактовать аварийное состояние как обычную прикладную ошибку. Попытка сформировать ответ, записать лог или продолжить обработку сама может завершиться новым сбоем.

Особенно опасно возвращать после такого перехвата фиктивный результат: вызывающий код увидит формально корректный ответ, хотя инварианты приложения уже могли быть нарушены. Это усложняет диагностику и способно привести к повреждению данных или каскаду вторичных ошибок.

Подробное решение

Обработчик catch(Throwable) подходит по типу для любого объекта, выброшенного в соответствующем try, поскольку все стандартные исключения и ошибки прямо или косвенно наследуются от Throwable. catch(Exception) охватывает RuntimeException и проверяемые исключения, но не охватывает ветвь Error.

Минимальный пример различия:

public class Demo {
    public static void main(String[] args) {
        try {
            throw new AssertionError("invariant");
        } catch (Throwable t) {
            System.out.println(t.getClass().getSimpleName());
        }
    }
}

Здесь будет перехвачен AssertionError, хотя это не Exception. Сам факт перехвата не делает восстановление безопасным: конкретный Error может означать, что выполнение текущей операции или всего процесса продолжать нельзя.

В прикладном коде обычно перехватывают наиболее узкий тип, который действительно можно обработать. На верхней границе потока или задания иногда перехватывают Throwable, чтобы гарантировать журналирование, но после этого сохраняют исходный объект и передают сбой дальше либо завершают выполнение. Такой boundary-обработчик не должен превращать неизвестную ошибку в успешный результат.

Есть и ограничения: Throwable включает не только Error, но и Exception, поэтому обработчик становится слишком широким и скрывает ошибки программирования. Кроме того, сам код обработки не гарантированно завершится успешно при исчерпанной памяти или разрушенном состоянии среды выполнения.

Ситуация из практики

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

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

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

Что кандидаты часто упускают

Означает ли перехват Error, что ошибку можно исправить?

Нет. Перехват — это только выбор обработчика по типу во время раскрутки стека. Например, после OutOfMemoryError нельзя полагаться на успешное выделение памяти для логирования или формирования ответа. Обработчик может зафиксировать минимум информации и завершить выполнение, но универсального восстановления нет.

Безопасно ли использовать catch(Throwable) для гарантированного логирования?

Только при понимании ограничений. Он действительно расширяет область, в которой можно попытаться записать сведения о сбое, но журналирование само может выбросить исключение или не сработать из-за состояния среды. Поэтому обработчик должен быть минимальным, не подменять исходную причину и не возвращать успешный результат без явной гарантии корректности.

Почему catch(Throwable) опасен даже там, где приложение не падает сразу?

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