Кратко и по существу — сравнение по ключевым аспектам: семантика, гарантия обработки (programmable reliability), удобство построения цепочек ответственности (chain of responsibility), плюсы/минусы и практические рекомендации.
1) Исключения (exceptions)
- Семантика: неявная сигнализация ошибки через переброс исключения; обработка через catch/try/finally; бывают проверяемые (checked) и непроверяемые (unchecked).
- Плюсы:
- Позволяют легко прервать глубоко вложенный поток выполнения и пробросить ошибку вверх, упрощая обработку в одном месте (удобны для цепочек ответственности).
- Меньше шума в сигнатурах функций (нет явных типов ошибок).
- Хороши для неожиданных/фатальных ошибок и для исключительных ситуаций.
- Полезны для наличия стек-трейса и диагностической информации.
- Минусы:
- Отсутствие явности: трудно гарантировать, что все важные ошибки обрабатываются — можно забыть catch и получить латентные баги.
- Контроль потока усложняется: исключения могут «прыгать» через слои, нарушая локальные инварианты, если не аккуратно.
- Производительность (в языках/реализациях) при частых бросках хуже.
- Труднее композиция и функциональная обработка ошибок; межъязыковая совместимость проблемна.
- Checked exceptions (например, Java) дают явность, но приводят к шуму в сигнатурах и «обёртке» ошибок.
Влияние на надёжность и CoR:
- Хороши для глобальной политики обработки (ловить в верхнем слое), но повышают риск пропуска ошибок и неожиданных побочных эффектов. Требуют дисциплины: чёткие границы где ловить/логировать/преобразовывать.
2) Возвращаемые коды (return codes, error codes, errno)
- Семантика: функция возвращает код состояния (обычно целое), а результат — через out-параметр или отдельную структуру.
- Плюсы:
- Простота и совместимость с низкоуровневым/системным кодом и FFI.
- Небольшая накладная стоимость (вызов без исключительной механики).
- Минусы:
- Легко игнорируются — программист может пропустить проверку кода (тихий провал).
- Отсутствует типовая информация об ошибке (если не вводить коды как enum), сложнее carry context/stack-trace.
- Шум: много условных проверок и boilerplate на каждом шаге.
- Плохо масштабируется в больших системах — сложнее собирать и преобразовывать ошибки по слоям.
- Влияние:
- Надёжность зависит от дисциплины и вспомогательных паттернов (макросы, helper-функции). Для цепочки ответственности требует явной передачи/проверки каждого шага; при хороших обёртках может быть адекватно, но обычно громоздко.
3) Типы-результаты (Result/Option, sum-types, либо Either/Validated)
- Семантика: функции возвращают тип-обёртку, например $\text{Result}<T,E>$ или $\text{Option}<T>$; обработка — через pattern-matching, combinators или операторы вроде $?$ в Rust.
- Плюсы:
- Явная типизация ошибок: компилятор/типовая система заставляют учитывать возможность ошибки — повышает надёжность.
- Лёгкая композиция: map/and_then/flatMap/try-операторы позволяют бесшовно строить цепочки и middleware без громоздких проверок.
- Можно создавать богатые, дискриминируемые типы ошибок с контекстом; удобно для тестирования и рефакторинга.
- Функциональные паттерны позволяют аккуратно агрегировать и валидировать ошибки (например, Validated для сбора множества ошибок).
- Безопасность: меньше неожиданных пропусков ошибок.
- Минусы:
- Шум в сигнатурах (везде виден $\text{Result}$), хотя в языках с синтаксическим сахаром это частично снимается.
- Если язык не поддерживает удобные combinators/операторы, код может стать громоздким.
- Иногда приводит к избыточной обработки «брошенных» ошибок в местах, где они действительно фатальны.
- Переход от библиотек с исключениями/кодами может требовать адаптации.
- Влияние:
- Лучший баланс для крупной системы: явность + удобная композиция. Для цепочки ответственности отлично подходит: можно явным образом передавать и трансформировать ошибки по слоям, или пробрасывать вверх с сокращённой синтаксической обёрткой (оператор ? в Rust).
Практические соображения и рекомендации
- Для доменных/ожидаемых ошибок (валидация, бизнес-правила, recoverable failure) — использовать тип-результат ($\text{Result}/\text{Option}$ или эквивалент). Это повышает надёжность и даёт контроль над цепочкой ответственности.
- Для непредвиденных/системных ошибок (OOM, баги в рантайме) — допустимо исключение; такие ошибки редко корректно обрабатываются на уровне приложения.
- Для низкоуровневого/FFI/встраиваемого кода — возвращаемые коды могут быть уместны, но оберните их в типы-результаты на границе модуля/слоя.
- Для API публичных библиотек: предпочитайте явные типы ошибок (typed Result/checked Either) или четко документируйте исключения; это делает контракты ясными.
- Для chain-of-responsibility паттернов:
- Если нужен implicit short-circuit — исключения дают это, но рискованно.
- Лучше использовать Result + combinators/операторы (например, middleware, где каждый слой возвращает Result и может map/and_then дальше). Это даёт контролируемый short-circuit + явность.
- Логирование и трассировка: независимо от механизма, стандартизируйте, где и как логируете/добавляете контекст — типовые ошибки упрощают автоматическое добавление контекста на каждом этапе.
Краткая сводка
- Exceptions: удобны для implicit propagation и неожиданных ошибок; опасны для надёжности без дисциплины.
- Return codes: низкоуровневы, просты, но легко игнорируются; требуют обёрток для безопасности в больших системах.
- Result/Option (typed results): лучший выбор для крупных систем с высокими требованиями к надёжности и управляемой цепочке ответственности — явные, композитные, легко тестируемые.
Используйте гибрид: тип-результат на краях модулей/домене + исключения для критических runtime-сбоев; в низкоуровневом коде — коды с обёртками.