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

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

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

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

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

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

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

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

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

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

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

class ConfigError(Exception):
    pass

try:
    try:
        raise UnicodeDecodeError("utf-8", b"\\xff", 0, 1, "invalid")
    except UnicodeDecodeError as error:
        raise ConfigError("Конфигурация повреждена") from error
except ConfigError as error:
    print(type(error.__cause__).__name__)
    print(type(error.__context__).__name__)

В примере __cause__ и __context__ указывают на исходную ошибку, но их смысл различается: первая отражает явно объявленную причину, вторая — исключение, активное во время обработки. При явной причинной связи Python обычно показывает исходную ошибку как причину нового исключения, а затем новое исключение.

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

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

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

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

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

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

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

Чем отличаются __cause__ и __context__?

__context__ содержит исключение, которое обрабатывалось в момент возникновения нового исключения. __cause__ появляется при явном указании причины и выражает намеренную причинную связь. Эти атрибуты могут ссылаться на один объект, но обозначают разные источники информации о связи.
Удаляет ли преобразование исключения исходную ошибку из памяти?

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

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