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

Обычный try-catch перехватывает исключения только в том потоке, где выполняется соответствующий try. Исключение распространяется по стеку вызовов текущего потока и не переходит автоматически в стек другого потока.

Если исключение не обработано внутри потока, оно передаётся его UncaughtExceptionHandler. Чтобы получить ошибку в другом потоке, её нужно явно передать: например, через Future, CompletableFuture, очередь сообщений или собственный механизм координации.

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

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

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

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

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

Если исключение останется необработанным в фоновом потоке, поток завершится, а приложение может продолжить работу в частично неисправном состоянии. В пуле потоков ситуация ещё менее очевидна: ошибка задачи может быть сохранена внутри объекта результата, а не немедленно выведена как необработанное исключение.

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

При возникновении исключения Java ищет обработчик в стеке текущего потока: сначала в текущем методе, затем в вызывающем, и так далее. Если обработчик не найден, поток завершает выполнение, а JVM вызывает UncaughtExceptionHandler; это механизм уведомления, а не способ передать исключение в другой поток.

Например, обработчик в main не поймает ошибку, возникшую в созданном потоке:

public class Demo {
    public static void main(String[] args) {
        try {
            Thread t = new Thread(() -> {
                throw new IllegalStateException("failure");
            });
            t.start();
        } catch (Exception e) {
            System.out.println("не сработает");
        }
    }
}

Здесь start() лишь запускает другой поток и быстро возвращает управление. Исключение возникает позже в стеке нового потока, поэтому внешний catch к нему не относится.

При использовании ExecutorService результат задачи обычно получают через Future. Для Callable исключение сохраняется в будущем результате и становится видимым при вызове get, обычно обёрнутым в ExecutionException. Это явный контракт передачи сбоя вызывающему коду.

Для CompletableFuture исключение становится частью состояния асинхронной цепочки и обрабатывается такими этапами, как exceptionally, handle или whenComplete. Важно не путать это с необработанным исключением потока: ошибка может быть корректно сохранена в объекте результата и не попасть в UncaughtExceptionHandler.

Компромисс зависит от задачи. UncaughtExceptionHandler подходит для последнего уровня журналирования и аварийного контроля, но не возвращает ошибку бизнес-коду. Future и CompletableFuture позволяют явно связать сбой с результатом операции, однако требуют дождаться результата или организовать дальнейшую обработку асинхронной цепочки.

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

Сервис отправляет документы в фоновом пуле потоков. В первой реализации задача передаётся через submit, но возвращаемый Future игнорируется. Ошибка сериализации сохраняется внутри Future, поэтому основной поток не получает уведомления, а оператор видит успешное завершение HTTP-запроса.

Рассматривались два варианта. Установка UncaughtExceptionHandler удобна для журналирования, но не помогает связать конкретный документ с результатом операции; переход на execute может сделать необработанные ошибки заметнее, но не создаёт надёжного протокола обработки. Проверка Future позволяет получить ошибку, однако синхронный вызов get может задержать запрос.

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

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

1. Перехватит ли UncaughtExceptionHandler исключение задачи, отправленной через submit в ExecutorService?

Обычно нет. Метод submit оборачивает задачу в FutureTask, а FutureTask сохраняет исключение внутри будущего результата; оно становится доступным через Future.get. Поэтому для такой задачи нужно обрабатывать ExecutionException при получении результата или строить явную асинхронную цепочку обработки.

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

2. Что произойдёт, если вызвать Future.get в другом потоке, но не обработать ExecutionException?

get сообщит о сбое задачи через ExecutionException, у которого исходная ошибка доступна как причина. Если вызывающий код проигнорирует этот результат или обработает только успешный путь, ошибка фактически не будет превращена в понятное бизнес-событие.

Кроме того, get может завершиться InterruptedException или CancellationException. Поэтому корректная обработка должна учитывать прерывание, отмену и саму причину выполнения, а не только проверять факт наличия объекта Future.

3. Можно ли считать завершение потока признаком успешного выполнения задачи?

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

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