Правильное использование механизма исключений

[yursdan]

Странный выбор уровня "Средний" без упоминания и раскрытия тем AutoCloseable под конструкцию try-with-resources и важной темы того, что throw это сравнительно дорогостоящее действие, которое в нагруженных системах по возможности избегают, если накладные расходы в коде (громоздкость/сложность) это позволяют, например: Mono.error c throwable, которое не будет throw в реакте.

[Alex_Shir]

Добрый день! Статья посвящена не механизму исключений в целом, а именно архитектурному применению исключений. Про оптимизацию речь не идет. Предполагается, что читатель уже знает, что такое try-catch, что исключения - это дорогостоящие операции.

Я бы не хотел, чтобы статья была уже об известных вещах (try-catch, try-with-resources), я хочу затрагивать именно архитектурные решения.

Как вы видите начало статьи, чтобы было понятно, что статья об архитектурных решениях, и чтобы не было заблуждения, что речь пойдет просто о механизме исключений? Возможно, поможете улучшить.

[LiamBlue]

В C++ исключения не такой уж и синтаксический сахар. Попробуйте в конструкторах обойтись без них. Также, исключения неудобно сочетать с многопоточностью. Как их перебрасывать между потоками?

[AbitLogic]

В Rust обходятся без исключений, в C++ аналоги тоже есть - std::optional и std::expected, менее удобные из-за отсутствия паттерн-матчинга, но функционально они соответствуют монадам Option и Result, поэтому не вижу проблем обходится без исключений

[mvuhanov]

Механизм исключений это вовсе не синтаксический сахар. И уж конечно не замена if-else.

Огромное количество ключевых слов, вводимых и обрабатываемых VM: try-catch-finally, throws, throw.

Дополнительно VM различает Exception и Error. А так же RuntimeException и его наследников, от unchecked exceptions (остальных).

Обработка исключения это затратная по времени операция, почему?

Потому, что нужно сохранить контекст для дальнейшего правильного выполнения кода, например - рассмотрите полный блок try с return в каждой ветке. Плюс нужно отложить выброс throw исключения при наличии блока finally - сначала выполнить его. А если в нем тоже throw?!

Дополнительно, нужно правильно раскрутить обратно стэк, при большом количестве вложений методов.

Я бы добавил в статью все эти детали, чтобы глубже раскрыть всю красоту и силу механизма исключений.

[Alex_Shir]

Добрый день!

Я специально не раскрывал тему механизма исключений, потому что это заезженная тема и доступна в любом учебнике.

Я пытался отразить в статье именно архитектурные решения. Бизнес ставит задачу, как стоит грамотно реализовывать в коде, чтобы код был прозрачен. Отмечу, про оптимизацию речь не идет. Речь идет о гибкости системы для бизнеса.

Вы в комментарии все равно не дали ответ на вопрос, почему исключения не синтаксический сахар. Вы перечислили факты об исключениях, но они вовсе не противоречат тому, что исключения похожи на синтаксический сахар с точки зрения именно самого ЯП.

Вы уходите в детали для новичков, но я хочу опираться на тех, кто уже собаку съел на исключениях, и предложить, как архитектурно можно улучшать код. Подскажите, чего вам не хватило в статье, чтобы интерпретировать, что акцент именно на архитектуре? Примеров побольше бизнесовых? Введение вводит в заблуждение?