Кратко, по пунктам — описание, влияние на надёжность, читаемость API и производительность, практические случаи применения.
1) Исключения (Java, C++)
- Что: управление ошибками выносится из основного потока; обработка через try/catch, при необработанном исключении — распространение стека.
- Надёжность: высокая при правильном использовании (неявная передача ошибок упрощает код), но легко пропустить нужный catch или подавить исключение; в Java есть checked/unchecked, что влияет на обязательность обработки.
- Читаемость API: сигнатуры часто чище (нет «шумных» кодов возврата), но поведение неявно — нужно читать доки, чтобы понять, какие исключения могут возникнуть.
- Производительность: частая оценка — «незначительная на нормальном пути, очень дорогая при выбрасывании»: ${\text{cost}}_{throw}\gg {\text{cost}}_{check}$. В C++/Java реализация часто оптимизирована для ненаошибочных путей (zero-cost), но unwind/создание стека/allocation при броске стоит дорого.
- Когда лучше: высокоуровневые приложения, когда ошибки редки и хочется чистой основной логики (GUI, бизнес-логика, скрипты), межмодульное управление ошибками с богатым стек-трейсом.
2) Возвращаемые коды (C)
- Что: функция возвращает код успеха/ошибки (int/enum); дополнительные данные через выходные параметры.
- Надёжность: низкая, если программист забывает проверить код; ошибок меньшая семантика (одночисленные коды) сложнее комбинировать.
- Читаемость API: сигнатуры простые, но вызовы «зашумлены» проверками после каждого вызова; документация обязана описывать коды.
- Производительность: минимальные накладные расходы на контроль (проверка/ветвление), предсказуемая. Нет стояков с unwind.
- Когда лучше: низкоуровневое/встраиваемое программирование, real-time, OS- и драйверный код, FFI, где исключения недопустимы или отсутствуют.
3) Типизированные результаты (Rust Result / Either)
- Что: возвращается алгебраический тип, например $\mathrm{Result}<T,E>$ или $\mathrm{Either}<E,T>$; компилятор/типовая система заставляет учитывать оба варианта.
- Надёжность: высокая — обработка либо явная, либо явно пробрасывается; возможность представлять богатую информацию об ошибке; композиция через combinators или оператор распространения ($?$ в Rust) делает обработку удобной и безопасной.
- Читаемость API: сигнатуры самодокументированы (видно, какие ошибки возможны); код обработчика может быть чище при наличии синтаксического сахара (pattern matching, ?).
- Производительность: аналогична возвращаемым кодам (ветвления/значения), без стоимости стек-раскачки; часто zero-cost abstractions.
- Когда лучше: системное программирование, библиотеки, где важна явная обработка, многокомпонентные системы, API, требующие строгого контроля ошибок; когда нужна композиция и трансформация ошибок.
4) Pattern matching (шаблонное сопоставление)
- Что: инструмент разбора значений ADT (algebraic data types) / суммарных типов (например, match в Rust/Scala/Haskell); обычно используется вместе с типизированными результатами.
- Надёжность: повышает — компилятор проверяет исчерпываемость ветвей; легко обрабатывать разные случаи детально.
- Читаемость API/кода: при хорошей модели типов делает обработку явной и структурированной; уменьшает boilerplate по сравнению с множеством if/else.
- Производительность: компилируется в ветвления/индексацию — обычно эффективен; накладные расходы сопоставимы с ручными ветвлениями.
- Когда лучше: при работе с ADT (парсеры, протоколы, сложные ошибки), когда нужно явно различать подтипы результата.
Сравнение и практические рекомендации
- Надёжность: типизированные результаты + pattern matching > исключения (при нестрогом использовании) > возвращаемые коды (когда проверки забывают). Причина: язык/компилятор принуждает обрабатывать случаи.
- Читаемость API: exception-based API выглядят чище, но менее явны; Result/Either делают контракт явным; return-codes засоряют вызовы.
- Производительность: при частых ошибках cost(throw) высок; в безошибочном потоке исключения могут быть «нулевой стоимостью», но всё равно риск просадок при броске. Return codes и Result сопоставимы и предсказуемы.
Типичные ситуации:
- Используйте исключения когда: ошибки редки, нужна простая основная логика, нужен стек-трейс и централизованная обработка (например, Java-серверы, бизнес-слой).
- Используйте возвращаемые коды когда: низкоуровневый код, реальное время, ограниченные среды без исключений (ядро ОС, встроенные системы).
- Используйте типизированные результаты + pattern matching когда: важно заставить клиента обработать ошибку, нужна композиция ошибок и явность (системное ПО, безопасные API, многокомпонентные библиотеки).
- Pattern matching особенно удобен когда у ошибок/результатов много подтипов и нужна исчерпывающая обработка (протоколы, парсеры, обработка состояний).
Короткая шпаргалка для выбора
- Простота использования + редкие ошибки → исключения.
- Производительность и предсказуемость + низкоуровневая среда → коды возврата.
- Безопасность, композиция, язык поддерживает ADT → Result/Either + pattern matching.
Если нужно, могу привести компактные примеры кода для каждого подхода.