Кратко перечислю основные подходы к обработке ошибок, объясню механизм, плюсы и минусы и где обычно применяется.
1) Исключения (exceptions) — Java, C#, Python, Ruby
- Как работает: при ошибке бросается исключение, управление переходит к ближайшему обработчику (try/catch) через стек (stack unwinding).
- Плюсы: отделяют нормальную логику от кода обработки ошибок; удобны при глубокой цепочке вызовов (не нужно явно передавать ошибку через каждый уровень); позволяют хранить стек-трейс.
- Минусы: неявность (ошибка может возникнуть где угодно, сложно понять по сигнатуре какие исключения бросаются); возможны пропущенные обработчики; runtime‑стоимость при броске; могут нарушать контроль потоков выполнения (используются не только для ошибок); checked‑exceptions (в Java) дают явность, но добавляют вербозность и могут заставлять писать «лишний» код.
- Когда годятся: случаи, когда ошибки редки и исключительны, либо когда удобнее централизованно обрабатывать ошибки (например, парсинг, IO).
2) Возврат кодов ошибок / специальных значений — C-стиль (int errno, NULL и т.п.)
- Как работает: функция возвращает код ошибки или специальное значение; вызывающий должен явно проверить.
- Плюсы: простая модель, низкая накладная стоимость, явный контроль потока.
- Минусы: легко забыть проверку — silent failures; смешение значения результата и кода ошибки (нужны хитрости); плохая композиция для цепочек вызовов; отсутствие типовой информации об ошибке.
- Когда годится: низкоуровневый код, производительность критична, системное программирование.
3) Явные типы результата (Result/Either/Validated) — Rust, Haskell, Scala
- Как работает: функции возвращают сумму типов, например $\text{Result<T, E>}$ или $\text{Either<E, T>}$; ошибка — отдельный тип, компилятор/типовая система заставляет обрабатывать или явно игнорировать.
- Плюсы: статическая явность (невозможно забыть обработать), хорошая композиция (map/and_then/flatMap), безопасное распространение ошибок, можно кодировать контекст ошибки в типе.
- Минусы: вербозность без удобных операторов; чуть больше шаблонного кода; нужно механизмы для удобной проброски ошибок (в Rust — оператор ${}^{\prime }{?}^{\prime }$).
- Когда годится: API с требованиями безопасности, когда важно статически гарантировать обработку ошибок; хорошо в многослойных системах.
4) Пара «значение, ошибка» (Go — multiple returns)
- Как работает: функции возвращают (value, error); вызывающий проверяет error явно.
- Плюсы: простая и понятная модель; явность и лёгкость отладки; хорошая читаемость мест, где ошибки вероятны.
- Минусы: много повторяющегося кода (if err != nil { ... }); композиция хуже, чем с Result; отсутствие статического контроля «обработано ли» (можно проигнорировать).
- Когда годится: сервисный/инфраструктурный код, где простота и предсказуемость важнее элегантности.
5) Nullable/Optional (null, Option)
- Как работает: функция возвращает значение или null/None/Option; отсутствие значения сигнализирует об ошибке/неудаче.
- Плюсы: простая семантика для «нет результата»; Option/Maybe хорошо сочетается с типовой системой.
- Минусы: не даёт информации об причине ошибки (только факт отсутствия); null prone ошибки; Option композиционно проще, но требует дополнительного способа описать причины.
- Когда годится: отсутствие значения — нормальная ситуация (поиск по базе, кеш miss).
6) Падение/паника (panic, abort) — неперехватываемые или частично перехватываемые ошибки
- Как работает: при критической ошибке программа паникует (может быть перехвачена или остановить процесс).
- Плюсы: проста; гарантирует немедленное прекращение выполнения при некорректном состоянии.
- Минусы: потеря возможности корректно восстановиться; небезопасна в длительных сервисах; сложнее тестировать.
- Когда годится: нехватка ресурсов, внутренние инварианты нарушены — «неисправимое» состояние.
7) Асинхронные ошибки / промисы (Promises/Futures) — JavaScript, Java CompletableFuture
- Как работает: ошибки передаются через rejected-branch промиса или поле результата Future; catch/await обрабатывают их.
- Плюсы: интегрированы с асинхронностью; цепочки обработки ошибок удобны при async flow.
- Минусы: модели обработки ошибок различаются в разных реализациях; возможны утечки ошибок при незакрытых промисах.
- Когда годится: асинхронный код, сетевые операции, concurrency.
8) Алгебраические эффекты / декларативные модели (experimental)
- Как работает: обработка ошибок превращается в эффекты, которые можно обрабатывать отдельно от кода.
- Плюсы: гибкая композиция, хорошая абстракция для cross-cutting concerns.
- Минусы: пока экспериментальные, сложнее понимать и внедрять.
- Когда годится: сложные DSL/фреймворки, где нужна мощная абстракция эффектов.
Краткое сравнение/рекомендации
- Если нужен строгий статический контроль и безопасная композиция — предпочитайте Result/Option (Rust/Haskell) + синтаксический сахар для проброса ошибок.
- Если важна простота и привычность — exceptions (для исключительных случаев) или Go‑стиль (для явной обработки) подойдут.
- Для низкоуровневого или высокопроизводительного кода — коды ошибок/NULL или тщательно спроектированные Result‑типы.
- Для асинхронного кода — промисы/futures с единообразной стратегией обработки.
- Паники/abort — только для действительно некорректного состояния.
Выбор зависит от требований к явности, производительности, композиции и удобству API.