Я специально не раскрывал тему механизма исключений, потому что это заезженная тема и доступна в любом учебнике.
Я пытался отразить в статье именно архитектурные решения. Бизнес ставит задачу, как стоит грамотно реализовывать в коде, чтобы код был прозрачен. Отмечу, про оптимизацию речь не идет. Речь идет о гибкости системы для бизнеса.
Вы в комментарии все равно не дали ответ на вопрос, почему исключения не синтаксический сахар. Вы перечислили факты об исключениях, но они вовсе не противоречат тому, что исключения похожи на синтаксический сахар с точки зрения именно самого ЯП.
Вы уходите в детали для новичков, но я хочу опираться на тех, кто уже собаку съел на исключениях, и предложить, как архитектурно можно улучшать код. Подскажите, чего вам не хватило в статье, чтобы интерпретировать, что акцент именно на архитектуре? Примеров побольше бизнесовых? Введение вводит в заблуждение?
Добрый день! Статья посвящена не механизму исключений в целом, а именно архитектурному применению исключений. Про оптимизацию речь не идет. Предполагается, что читатель уже знает, что такое try-catch, что исключения - это дорогостоящие операции.
Я бы не хотел, чтобы статья была уже об известных вещах (try-catch, try-with-resources), я хочу затрагивать именно архитектурные решения.
Как вы видите начало статьи, чтобы было понятно, что статья об архитектурных решениях, и чтобы не было заблуждения, что речь пойдет просто о механизме исключений? Возможно, поможете улучшить.
Добрый день!
Я специально не раскрывал тему механизма исключений, потому что это заезженная тема и доступна в любом учебнике.
Я пытался отразить в статье именно архитектурные решения. Бизнес ставит задачу, как стоит грамотно реализовывать в коде, чтобы код был прозрачен. Отмечу, про оптимизацию речь не идет. Речь идет о гибкости системы для бизнеса.
Вы в комментарии все равно не дали ответ на вопрос, почему исключения не синтаксический сахар. Вы перечислили факты об исключениях, но они вовсе не противоречат тому, что исключения похожи на синтаксический сахар с точки зрения именно самого ЯП.
Вы уходите в детали для новичков, но я хочу опираться на тех, кто уже собаку съел на исключениях, и предложить, как архитектурно можно улучшать код. Подскажите, чего вам не хватило в статье, чтобы интерпретировать, что акцент именно на архитектуре? Примеров побольше бизнесовых? Введение вводит в заблуждение?
Добрый день! Статья посвящена не механизму исключений в целом, а именно архитектурному применению исключений. Про оптимизацию речь не идет. Предполагается, что читатель уже знает, что такое try-catch, что исключения - это дорогостоящие операции.
Я бы не хотел, чтобы статья была уже об известных вещах (try-catch, try-with-resources), я хочу затрагивать именно архитектурные решения.
Как вы видите начало статьи, чтобы было понятно, что статья об архитектурных решениях, и чтобы не было заблуждения, что речь пойдет просто о механизме исключений? Возможно, поможете улучшить.