Коротко и по существу — сравнение по ключевым аспектам и выводы для дизайна API и тестируемости.
- Явность и контракт API
- Функциональные (ошибки как значения): сигнатура делает ошибку видимой: например $f:X\to \mathrm{Maybe}Y$ или $g:X\to \mathrm{Either}EY$. Это явно документирует возможность ошибки и её тип, заставляет клиента учитывать результат.
- Императивные (исключения): сигнатура обычно не показывает, какие исключения могут быть выброшены; поведение скрыто, контракт слабее.
- Коды возврата: видимы в API, но легко игнорируются и не интегрируются в типовую систему.
- Принудительное/непринудительное обращение с ошибкой
- $\mathrm{Maybe}/\mathrm{Either}$: компилятор и типы стимулируют обработку (или явное игнорирование). Это снижает вероятность забытых путей обработки.
- Исключения: обработка необязательна, ошибки могут всплыть далеко от места возникновения; легко пропустить ветви ошибок в тестах.
- Коды возврата: требуют явной проверки; практика часто приводит к пропущенным проверкам.
- Композиция и абстракции
- Монады/Result/Either: хорошая композиция цепочек операций (\( \bind \), for-comprehensions), лёгко комбинировать и передавать дальше; чистые функции остаются тестируемыми. Для накопления ошибок нужны аппликативы (Validation) — стандартный монадический подход коротит цепочку, а аппликатив позволяет собирать несколько ошибок.
- Исключения: композиция неявная — контроль потока ломается «вне» цепочки, сложнее комбинировать параллельные ветки с аккумулированием ошибок.
- Коды возврата: композиция приходится писать вручную и часто приводить к шаблонному проверочному коду.
- Чистота, побочные эффекты и тестируемость
- Ошибки как значения: функции остаются чистыми (если не используют побочные эффекты), легко юнит-тестировать все ветви (успех/ошибка) без инфраструктуры. Меньше неожиданного глобального состояния.
- Исключения: требуют ловли/фреймворков для проверки; побочные эффекты и non-local control flow усложняют изоляцию в тесте.
- Коды возврата: тестировать просто, но нужно отдельно проверять, что вызывающий код правильно обрабатывает коды.
- Богатство информации об ошибке и типизация
- $\mathrm{Either}/\mathrm{Result}$: позволяют хранить богатую структурированную информацию об ошибке (типы ошибок), что упрощает обработку и проверку в тестах.
- Исключения: можно иметь иерархию типов исключений, но она часто используется менее структурированно; при динамических языках типы могут теряться.
- Коды возврата: обычно числовые/строковые коды — беднее семантика, сложнее выразить причинно-следственные данные.
- Производительность и удобство разработки
- Исключения часто удобнее и лаконичнее для «быстрого» кода и редких ошибок; могут быть оптимизированы на уровне рантайма.
- Ошибки как значения добавляют «шум» в сигнатуры и требуют обёрток/шаблонов, но дают правильные гарантии.
- Коды возврата иногда быстрее в критических местах, но ведут к многословному и хрупкому коду.
- Интероперабельность и границы слоёв
- Для публичных библиотек и API предпочтительнее возвращать $\mathrm{Result}/\mathrm{Either}$ — ясный контракт и лёгкая проверка.
- На границе с императивным кодом/фреймворком можно конвертировать в/из исключений: внутри системы — значения ошибок, снаружи — исключения для совместимости.
Рекомендация по дизайну API и тестируемости (практически):
- Предпочитайте ошибки как значения (например $\mathrm{Result}<E,A>$ / $\mathrm{Either}EA$) для библиотек и чистых функций — это улучшает читаемость контракта и тестируемость.
- Используйте аппликативы, если нужно аккумулировать несколько ошибок; используйте монадический подход для короткого выхода при первой ошибке.
- Для интеграции с императивными средами предоставляйте тонкие адаптеры, которые превращают Result в исключение или обратно.
- Избегайте «сырого» использования кодов возврата в публичных API, если только это не требование платформы; если их используете — обеспечьте вспомогательные проверки/обёртки, чтобы снизить риск игнорирования.
Итого: ошибки как значения дают лучшие статические гарантии, композицию и тестируемость; исключения дают удобство и лаконичность, но ослабляют контракт и усложняют тесты; коды возврата явны, но легко игнорируются и порождают шаблонный код. Выбор зависит от требований к надежности, совместимости и ergonomics.