Кратко и по сути — сравнение, когда что использовать, влияние на читаемость/трассируемость/безопасность и как не допустить утечек ресурсов.

Основные подходы

Исключения (Java/C++/C#):
Плюсы: отделяют нормальный поток от ошибок (меньше шумовой проверки), автоматически дают стек‑трейс, удобны для «внезапных»/непредвиденных ошибок.Минусы: скрытая неконтролируемая точка выхода (особенно при отсутствии декларации throws), можно случайно проглотить (swallow) ошибку, могут быть дорогими в высокочастотных циклах, checked‑исключения (Java) дают шум и могут спровоцировать пустые перехваты.Возвращаемые коды/статусы (C):
Плюсы: простая, предсказуемая семантика; дешевы по производительности; ясно при интерфейсах на C/FFI.Минусы: легко забыть проверку, много шаблонного кода, затруднённая композиция и трассировка причины (нет автоматического стека).Типы результата (Option/Result, Rust/функциональный стиль):
Плюсы: ошибки — часть типа -> компилятор заставляет обрабатывать; легко комбинировать/транслировать; безопаснее (нет «невидимых» исключений); хорошо для документирования API.Минусы: может быть многословно без удобных операторов (хотя ?, map, and_then уменьшают шаблонность); по умолчанию нет автоматического стека — нужен контекст/обёртки.

Когда «бросать» (throw) исключение, а когда возвращать ошибку

Используйте исключения когда:
Ошибка исключительная, неожиданная и вы не ожидаете обычной локальной обработки (например, внутренняя непредвиденная ошибка среды выполнения).Язык и кодовая база принятыми конвенциями пользуются исключениями (Java/C#).Нужен автоматический стек‑трэйс для диагностики.Возвращайте ошибку/используйте Result/Option когда:
Ошибка — ожидаемая часть нормального потока (например, EOF, проверка пароля не прошла, парсинг валидируемых входных данных).Хотите явной, статически проверяемой обработки ошибок (без риска проглатывания).Производительность критична (внутренние горячие пути).API кроссует границу FFI/с/низкоуровневые интерфейсы.Практическое правило: если вызывающий код имеет осмысленную стратегию восстановления — возвращайте ошибку; если только наружняя среда/логирование/откат может решить — исключение.

Влияние на читаемость, трассируемость и безопасность

Читаемость:
Исключения уменьшают «шум» локального кода, но скрывают контракт (что может броситься) — ухудшает понимание API.Коды ошибок делают контракт явным, но приводят к многословию.Result/Option делают контракт явным в типах и дают баланс: ясность + меньше шаблонного контроля при наличии операторов (например, ?).Трассируемость:
Исключения дают стек‑трейс по умолчанию.Коды ошибок — трассировка должна дополняться логированием/контекстом вручную.Result/Option: нужно явно добавлять контекст/цепочку причин (error chaining) — тогда трассируемость хорошая.Безопасность (устойчивость к ошибкам):
Исключения: риск проглатывания, неожиданный переход выполнения; но при правильном использовании — безопасно (RAII/финализаторы).Коды ошибок: легче пропустить проверку -> баги; программистская дисциплина критична.Result/Option: сильнее защищают компилятором от игнорирования ошибок.

Как избегать утечек ресурсов при ошибках

Используйте scope‑bound cleanup:
C++: RAII — обертки (std::unique_ptr, std::lock_guard, потоковые обёртки) и деструкторы выполняются при unwinding.Rust: ownership + Drop автоматически очищает при панике/ошибке.Java/C#/Python: try-with-resources / using / with / finally — закрывать ресурсы в блоке, который выполняется при исключении.C: явные вызовы cleanup в каждом месте выхода либо использовать scope guards/конструкции (например, goto cleanup).Всегда централизуйте управление ресурсом: обёртки/контейнеры, которые гарантируют закрытие.Не глотайте ошибки в finally/finalizer: логируйте и, если нужно — повторно пробрасывайте или возвращайте информацию об ошибке.При использовании кодов ошибок: проверяйте ошибки сразу, и в каждом раннем выходе выполняйте общий cleanup‑блок (patterns: goto cleanup).Для асинхронного/параллельного кода — гарантируйте отмену/отключение через токены отмены и корректный join/await.В комбинации типов: если используете Result/Option, возвращайте Result с контекстом (error chain), чтобы при логировании был полезный контекст ошибки.

Рекомендации по дизайну API

Быть последовательным в проекте: смешение стилей усложняет жизнь.Документировать — какие ошибки могут возникнуть и семантику (в throw/в типе результата).Для публичных библиотек: в языках с типами результата — отдавайте Result/Option; в языках без — хорошо документируйте исключения или используйте явные коды и удобные обёртки.Всегда добавляйте контекст при распространении ошибки (wrap/with_context), чтобы трассировка имела смысл.Не использовать исключения для контроля потока (unless language idiom allows it).

Краткое резюме

Исключения — удобно для неожиданных/фатальных ошибок и дают стек‑трейс, но скрывают контракт и легко проглатываются.Коды ошибок — просты и быстры, но склонны к ошибкам из‑за человеческого фактора и громоздки.Result/Option — лучший компромисс там, где доступны: явность, безопасность и композиция; нужно дополнять контекстом для хорошей трассировки.Для предотвращения утечек ресурсов используйте scope‑based cleanup (RAII/using/finally/defer) и не глотайте ошибки без логирования/повторной передачи контекста.