Кратко, по пунктам — описание, плюсы/минусы, когда применять, влияние на архитектуру и тестируемость, практичные рекомендации.
1) Исключения (exceptions)
- Что: механизм немедленного прерывания нормального потока и передачи ошибки вверх (try/catch).
- Плюсы: читаемый код в «нормальном» случае (нет постоянной проверки возвратов); удобны для непредвиденных/крайних ситуаций; хорошо поддержаны во многих ЭКО‑системах (Java, Python, C#).
- Минусы: неявный контроль потока, трудно проследить все места обработки; могут скрывать ресурсы/состояние; дорогостоящи в hot‑path; усложняют reasoning и static analysis.
- Когда: для действительно исключительных, непредвиденных или фатальных ошибок; когда язык/библиотека ожидает exceptions.
- Влияние на архитектуру/тестируемость: требует явных границ обработки (error boundaries), централизованного логирования и очистки ресурсов (finally/RAII). Тесты проверяют, что исключение выбрасывается/ловится; нужно тестировать сценарии высотного распространения ошибок.
2) Коды ошибок (error codes / errno)
- Что: функция возвращает числовой/символьный код (или устанавливает глобальный errno).
- Плюсы: простая, низкоуровневая, минимальна по накладным расходам; удобна в embedded/системном C/FFI.
- Минусы: легко забыть проверку; коды часто не типизированы и неинформативны; плохая композиция.
- Когда: низкоуровневый код, совместимость C-API, ограниченные ресурсы, интерфейсы между языками.
- Влияние: код насыщается проверками; архитектура должна предусматривать явную обработку каждого вызова; тестируемость зависит от императивных проверок.
3) Типы результата (Result/Either, sum types)
- Что: функции возвращают тип вроде $\mathrm{Result}⟨T,E⟩$ или $\mathrm{Either}$ — явно «успех/ошибка».
- Плюсы: явно в сигнатуре, заставляют обрабатывать все случаи; хороши для композиции (map/flatMap, ?/bind); безопаснее и предсказуемее; облегчают статическую проверку и рефакторинг.
- Минусы: больше boilerplate без синтаксической поддержки; нужно моделировать типы ошибок (иногда трудоёмко).
- Когда: бизнес‑логика, публичные API, библиотечный код, функциональные/строгие типизированные системы.
- Влияние: архитектура становится более явной и тестируемой — легко писать модульные тесты для обоих ветвлений; упрощают внедрение retry/compensation и преобразование ошибок между слоями.
4) Утверждения (assertions)
- Что: проверка инвариантов, обычно ведёт к аварийному завершению (assert).
- Плюсы: быстрый fail‑fast при нарушении контрактов; полезны в разработке/CI.
- Минусы: не для recoverable ошибок; могут быть отключены в production; не предназначены для коммуницирования ошибок пользователю.
- Когда: проверка внутренних инвариантов, предусловий/постусловий, контрактов в коде, defensive programming.
- Влияние: повышают надёжность кода в ранней стадии, но не заменяют обработку runtime‑ошибок; тесты должны покрывать контракты, а не полагаться только на assert.
5) Как выбирать и комбинировать
- Разделяй категории ошибок: transient vs permanent, expected vs unexpected, user vs programmer error. Модель обработки зависит от категории.
- Низкоуровень коды → поднимаются/преобразуются в typed errors/Result для бизнес‑слоя.
- Используй exceptions для непредвиденных/фатальных случаев и интеграции со стеком языка; используй $\mathrm{Result}$ для всех ожидаемых/восстанавливаемых ошибок.
- Для внешних API предпочти явные типы ошибок (или структурированные коды) — это улучшает совместимость и документирование.
- Assertions — только для нарушений контрактов/багов, не для пользовательских ошибок.
6) Влияние на тестируемость и практики тестирования
- Result/Either: легко тестировать обе ветви (Ok/Err), подменять ошибки, писать property‑tests и симулировать ошибки.
- Exceptions: тесты проверяют выброс/пойманность; сложнее покрыть цепочки распространения и side‑effects.
- Error codes: нужно тестировать явные проверки после каждого вызова; проще интеграционно тестировать взаимодействия C‑API.
- Общие практики: вводить fault injection, симулировать transient errors (timeouts, network), покрывать retry‑логики, логирование и метрики. Моделируй ошибки в отдельной иерархии/ADT, чтобы тесты могли легко создавать нужные случаи.
7) Практические рекомендации (четкие правила)
- Для domain/бизнес‑логики — предпочитай явные Result/typed errors; это улучшает читаемость, композицию и тестируемость.
- Для библиотек/фреймворков — явные ошибки в API + хорошие конвертации; допускай exceptions там, где язык этого ожидает.
- Для системного/встроенного ПО — error codes/errno, но документируй и автоматически проверяй (lint, CI).
- Всегда разделяй transient/permanent и делай retry только для transient; помечай ошибки контекстом при пропуске вверх (wrap + cause).
- Логирование/трейсинг + метрики обязательны для production‑ошибок; тестируй обработку ошибок и side‑effects (cleanup, retries).
Короткое резюме: используйте exceptions для действительно исключительных состояний или когда это идиоматично для языка; используйте коды ошибок на низком уровне и в constrained environments; используйте $\mathrm{Result}$/Either и типизированные ошибки для бизнес‑логики и публичных API — это делает архитектуру явной и тестируемой; assertions — для инвариантов и багов, не для пользовательских ошибок.