Подходы к обработке ошибок — кратко, с примерами языков и trade‑off'ами.
1) Код возврата (return codes / errno)
- Что: функция возвращает целое/enum, $0$ обычно — успех, ненулевые — ошибки; подробности в глобальной переменной (например, `errno`).
- Языки/места: C, POSIX API.
- Плюсы: простота, низкие накладные расходы, легко interop/FFI.
- Минусы: легко пропустить (непроверенные коды), неявная причина, плохая композиция, неструктурированная информация.
- Где годится: низкоуровневый код, драйверы, критичный по производительности код.
2) Исключения (exceptions)
- Что: ошибка прерывает обычный поток, создаётся/бросается объект ошибки, стек разворачивается или используется альтернативная модель (longjmp, unwind).
- Языки: Java, Python, C++, C#.
- Плюсы: удобная передача ошибок через стек, локальная обработка, хороши для «исключительных» ситуаций, понятный синтаксис try/catch, поддержка rich error objects и стека.
- Минусы: невидимая стоимость (unwinding), контроль потока неявен, могут ломать инварианты при неправильной обработке, при использовании в API возможны сложности с совместимостью и документированием того, что может быть брошено. Checked exceptions (Java) дают явность, но ведут к громоздкости.
- Где годится: приложениеного уровня код, где нужен удобный контроль потока и богатая информация об ошибке.
3) Option / Result (алгебраические типы ошибок)
- Что: возвращаем тип, инкапсулирующий либо значение, либо отсутствие/ошибку: Option/Maybe (значение или пусто), Result/Either (Ok(value) или Err(error)).
- Языки: Rust, Haskell (Maybe/Either), OCaml, Swift (Result), TypeScript/FP библиотеки.
- Плюсы: явность, безопасное обязательное обращение к результату, простая композиция (map/and_then), легко тестировать и рефакторить; хороши для recoverable ошибок; в Rust — нулевые накладные через оптимизацию.
- Минусы: вербозность без синтаксического сахара; если ошибку нужно пробросить через несколько уровней, требуется boilerplate (сокращения: `?` в Rust); неудобно для truly-exceptional control flow.
- Где годится: библиотеки с чётко типизированными API, критично безопасный код, функциональный стиль.
4) Контрактные проверки (assertions, pre/postconditions, design by contract)
- Что: явные проверки предпосылок/постусловий/инвариантов; при нарушении — аварийное завершение/raise.
- Языки/инструменты: Ada/SPARK, Eiffel, C/C++ assert, Rust debug_assert!, статические анализаторы.
- Плюсы: ловят программистские ошибки на раннем этапе, помогают документировать ожидания, облегчают верификацию.
- Минусы: не для recoverable ошибок; в релизе могут быть отключены (и тогда поведение undefined), не дают богатой информации о runtime‑ошибках.
- Где годится: защита внутренних инвариантов, контракты публичных API для разработки и тестирования.
Дополнительные аспекты
- Классификация ошибок: разумно разделять recoverable (e.g., сетевые таймауты) и programmer errors (инварианты). Разные механизмы: recoverable → Result/return code/exceptions; programmer errors → assert/unwrap/panic.
- Контекст/trace: ошибки должны сохранять трассировку/контекст (wrapping, cause chains). В return‑code подходе — труднее.
- Производительность: return codes и Result (в оптимизированных компиляторах) часто дешевле исключений; исключения выигрывают в удобстве но платят при throw.
- Межъязыковой boundary (FFI): избегать передачи исключений через границу; предпочтительнее возвращать коды/структурированные ошибки.
- Игнорирование ошибок: в языках с явными типами (Result) компилятор чаще помогает; в C/Go — легко забыть проверить.
Рекомендации для библиотечных API vs пользовательского кода
- Библиотеки (публичные API):
- Предпочтение: явные и типизированные ошибки (enum/Result/typed error objects) или документированные исключения. Явность облегчает обработку и forward‑compat.
- Причины: стабильность ABI, возможность автоматической обработки, ясная классификация ошибок, удобство для FFI.
- Практики: использовать error‑types с semantic variants, предоставлять способы получить трассировку/код/пояснение; не бросать необъявляемые исключения через boundary; обеспечить ergonomic helpers (converters, builders).
- Пользовательский/приложенческий код:
- Предпочтение: удобство и читаемость — исключения (в JVM/Python) или Result/Option с синтаксическим сахаром (в Rust/Swift). Для быстрых скриптов — исключения или panic допустимы.
- Практики: ловить только там, где можно восстановиться; логировать и снабжать контекстом; использовать assertions для внутренних инвариантов.
- Кросс‑cutting:
- Для публичных библиотек в многопользовательской экосистеме лучше явно документировать error model и предоставлять stable error identifiers (коды/enum); избегать «тонких» unchecked ошибки, которые трудно интерпретировать.
- Для критичного к латентности кода стараться минимизировать unwinding; для безопасности — предпочитать типы, которые заставляют учитывать ошибку.
Короткие эмпирические правила
- Если ошибка может быть ожидана и обработана — используйте Result/return code/explicit value.
- Если ошибка действительно исключительная и восстановление не имеет смысла — используйте исключение/panic/assert.
- Библиотеке: явность и стабильность API; клиентскому коду — удобство и краткость.
- На FFI‑границе: никогда не релайте непойманные исключения через границу; возвращайте структурированную ошибку.
Если нужно — могу привести конкретные примеры API‑дизайна в выбранном языке (Rust/Go/Java/C) и показать шаблон error‑enum/каррирования обработки.