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

Необработанное исключение завершит только поток, в котором оно возникло. Основной поток продолжит работу, если сам не ожидает поток через механизм, который явно передаёт ему ошибку, например Future.result().

По умолчанию исключение будет выведено через обработчик threading.excepthook, но автоматически в основной поток оно не попадёт и другие потоки не остановит.

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

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

Поэтому исключение относится к конкретному потоку, а не к процессу в целом. Это отличается от обычного последовательного вызова функции, где исключение распространяется по стеку вызовов вызывающего потока.

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

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

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

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

У обычного threading.Thread необработанное исключение обрабатывается внутри инфраструктуры потока. Поток завершается, после чего Python вызывает threading.excepthook; стандартный обработчик печатает информацию об исключении. Исключение не поднимается в вызывающем потоке и не прерывает его выполнение.

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

import threading
import time

def worker():
    raise RuntimeError("ошибка фоновой задачи")

thread = threading.Thread(target=worker)
thread.start()
time.sleep(0.1)
print("основной поток продолжает работу")

В результате ошибка будет напечатана, поток worker завершится, а основной поток напечатает свою строку. В реальном коде полагаться на sleep для синхронизации не следует; он приведён только для краткости примера.

thread.join() ждёт завершения потока, но сам по себе не повторно выбрасывает исключение. Если нужна передача ошибки вызывающему коду, её можно явно сохранить в объекте-результате, передать через очередь или использовать concurrent.futures.ThreadPoolExecutor.

У ThreadPoolExecutor исключение сохраняется в Future. Оно будет выброшено в том потоке, который вызовет future.result(), поэтому обработчик должен обязательно проверять результат задачи. Это удобнее для управления ошибками, но не означает автоматической остановки уже запущенных задач.

Переопределение threading.excepthook позволяет централизованно логировать необработанные исключения потоков. Однако логирование и передача ошибки — разные задачи: hook не должен молча подменять протокол завершения или создавать неуправляемые побочные эффекты.

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

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

Сервис запускает фоновый поток, который читает задания из очереди и записывает результаты в базу. Из-за временной ошибки подключения поток завершается, а HTTP-сервер продолжает принимать запросы и добавлять задания в очередь.

Рассматривались два варианта. Первый — оставить обычный Thread и рассчитывать на вывод traceback: это просто, но ошибка может остаться незамеченной, а очередь начнёт расти. Второй — запускать работу через ThreadPoolExecutor, проверять Future и при ошибке инициировать кооперативную остановку сервиса: это требует дополнительного контроля жизненного цикла, зато делает отказ наблюдаемым.

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

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

Остановит ли join() основной поток, если в присоединяемом потоке было исключение?

Нет. join() блокирует вызывающий поток до завершения целевого потока, но после этого возвращает управление без повторного выброса исключения. Если нужно узнать причину сбоя, её надо сохранить отдельно или получать через Future.result().

Может ли необработанное исключение в одном потоке автоматически прервать другие потоки?

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

Флаг daemon не превращает исключение в механизм управления ошибками. Демон-поток лишь не препятствует завершению процесса, поэтому его ресурсы и незавершённая работа могут быть брошены при завершении программы.

Чем отличается необработанное исключение в Thread от исключения в задаче ThreadPoolExecutor?

В обычном Thread исключение по умолчанию обрабатывает threading.excepthook, а вызывающий код не получает его автоматически. В ThreadPoolExecutor исключение сохраняется внутри Future и обычно становится видимым при вызове future.result().

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