Кратко — основное различие в явности и типовой безопасности: Maybe/Option и Either/Result делают возможность ошибки частью типа и принуждают обрабатывать/явно игнорировать её; исключения в императивных языках выносятся из сигнатуры и позволяют отделить «обычный» код от ветвления ошибок, но делают обработку неявной и потенциально пропускаемой.
Детали и последствия для дизайна API:
- Семантика и гарантии
- Option/Maybe: возвращает либо значение, либо отсутствие. Явно моделирует «нет результата» без объяснения причины; безопасно для случаев, где отсутствие — нормальная ситуация.
- Either/Result: возвращает либо успех с значением, либо ошибку с контекстом; позволяет типизировать причину неудачи.
- Исключения: не входят в сигнатуру (в большинстве языков) — ошибка проявляется в динамике выполнения, не компиляторно, а в runtime.
- Явность в API
- Option/Result в сигнатуре заставляют пользователей учитывать ошибки уже на этапе компиляции/чтения API: обработка видна на уровне типов.
- Исключения позволяют «чистую» сигнатуру (return T), но скрывают условность — пользователь может забыть обработать ошибку или не знать о ней без документации.
- Композиция и управление потоком
- Функциональные типы хорошо композируются: map/flatMap/and_then (bind) упрощают цепочки операций и автоматическую проброску ошибок без try/catch.
Пример (Rust-подобно):
let r = parse(s).and_then(validate).and_then(save);
- Исключения позволяют использовать try/catch для явного централизованного перехвата; для последовательной обработки нужна явная конструкция try или много вложенных проверок.
- Обработка и локализация ошибок
- Result/Either позволяет возвращать структурированный контекст ошибки (ошибка уровня парсинга vs. I/O) и делать pattern matching для точечного recovery.
- Исключения дают стек вызовов и быстрый путь выхода из глубоко вложенного кода, но менее удобны для составления и комбинирования ошибок и для типобезопасной обработки разных классов ошибок.
- Побочные эффекты и чистота
- В функциональном стиле явно показывают побочные эффекты: возвращая Result от функции, вы сигнализируете, что операция может провалиться (побочный результат). Это упрощает тестирование и рассуждения о коде.
- Исключения скрывают эффект от типа, уменьшая предсказуемость и усложняя формальную верификацию.
- ergonomics и удобство
- Option/Result требуют шаблонной обработки (match, unwrap, ?-оператор). Это увеличивает явный код, но снижает ошибки времени выполнения.
- Исключения короче в простых случаях (throw), удобны для «неожиданных» ошибок, но риск runtime-crash при непросмотренных исключениях.
- Производительность и накладные расходы
- Option/Result обычно минимальны по накладным расходам (обычно без аллокаций), их компоновка эффективна; однако явная проверки может добавлять код.
- Исключения в некоторых реализациях дороже (особенно при генерации стека и броске), но если исключения редки, накладные расходы фиктивны.
- Парадигмы использования (рекомендации)
- Использовать Option/Maybe для «возможного отсутствия» значения, где отсутствие ожидаемо и не требует объяснения.
- Использовать Result/Either для операций с возможностью ошибки, когда важно типизировать причину и поддержать композируемую обработку.
- Использовать исключения для truly-exceptional ситуаций, когда ошибка непредвиденна и не должна загромождать сигнатуры, либо при интеграции с библиотеками/фреймворками, ориентированными на исключения.
Короткий вывод: выбор влияет на дизайн API — Option/Result делают контракт явным и безопасным, улучшают композицию и тестируемость; исключения упрощают сигнатуры и позволяют быстро выйти из глубокой вложенности, но переносят ответственность на документацию и discipline команды.