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

Используйте повторный выброс без указания объекта исключения — оператор raise внутри обработчика. Он передаёт текущее исключение дальше, сохраняя его исходную трассировку и тип.

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

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

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

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

Вариант raise exc выглядит похожим, но явно выбрасывает объект заново. При этом в трассировку добавляется место такого выброса, что может усложнить диагностику и отличается от семантики чистого повторного выброса.

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

Безаргументный raise работает только в контексте активно обрабатываемого исключения, обычно внутри блока except. Python берёт текущее исключение из контекста обработки и продолжает его распространение вверх по стеку.


def read_value():
    try:
        return int("not-a-number")
    except ValueError:
        print("Ошибка записана в журнал")
        raise

read_value()

В примере ValueError не заменяется другим исключением: после сообщения он продолжает распространяться к вызывающему коду. Если выполнить безаргументный raise вне активной обработки, Python выдаст ошибку RuntimeError, поскольку повторно выбрасывать нечего.

raise exc применяют, когда требуется явно выбросить конкретный объект, но для простого проброса текущей ошибки это менее точный вариант. Если нужно добавить смысловой контекст, используют новое исключение с явной причиной через raise новое_исключение from exc; это уже не повторный выброс, а формирование цепочки исключений.

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

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

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

Выбран третий вариант: нижний слой сохраняет исходный тип исключения и трассировку, а верхний слой может отдельно обработать ValueError, OSError или другой ожидаемый тип. Результат — журналирование не меняет контракт функции и не маскирует неисправность.

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

1. Чем безаргументный raise отличается от raise exc?

Безаргументный вариант повторно передаёт текущее исключение в рамках его обработки. raise exc явно выбрасывает объект и обычно добавляет текущую точку в его traceback, поэтому для прозрачного проброса ошибки предпочтителен первый вариант.

2. Что произойдёт, если обработчик просто завершится без raise?

Исключение будет считаться обработанным, если внутри обработчика не возникнет другая ошибка. Функция продолжит выполнение после конструкции try/except или вернёт результат, заданный в обработчике, поэтому вызывающий код не узнает об исходном сбое.

3. Как добавить контекст, не потеряв исходную причину?

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