Существует мнение, что
Try/Catch — это признак плохого тона. Якобы, если ты используешь эту конструкцию, значит, заранее расписываешься в том, что твой код может упасть с ошибкой.В идеальном мире это, может, и так, но в реальности мы работаем в агрессивной среде. У нас есть внешние API, сторонние библиотеки и сеть, которая имеет свойство отваливаться в самый неподходящий момент. Мы не контролируем всё окружение, поэтому
Try/Catch — это не костыль, а механизм выживания системы.Проблема не в самой конструкции, а в том, как её превращают в «глушитель».
Антипаттерн «Изолента»
Самый лютый грех, который я вижу на ревью — это пустой блок
Catch. Разработчик видит, что кусок кода падает, не может (или не хочет) разобраться в причинах и просто оборачивает его в Try, оставляя обработчик ошибки пустым.Это чистой воды технический суицид. Представьте, что в машине загорелся значок Check Engine. Вместо того чтобы ехать в сервис, вы просто заклеиваете лампочку черной изолентой. Машина продолжает ехать? Да. Но прямо сейчас внутри двигателя может происходить катастрофа, которая через сто километров превратит машину в груду металлолома.
В программировании это работает так же. Ошибка произошла, но вы о ней не узнали. Вы её не залогировали, не оповестили пользователя, не сохранили контекст. Это технический долг с дикой процентной ставкой, который копится ежедневно.
Стратегия официанта
Адекватный инженер использует стратегию «официанта». Если на кухне произошел факап и блюдо сгорело, хороший официант не делает вид, что всё в порядке, вынося пустую тарелку. Он подходит, извиняется, объясняет причину и предлагает альтернативу.
В коде это реализуется через три обязательных шага в блоке
Catch:1. Сбор контекста: Логируем всё, что поможет расследовать инцидент — Payload запроса, ID пользователя, состояние переменных.
2. Обработка: Мы либо прокидываем ошибку выше по стеку, если не можем её решить здесь, либо подготавливаем объект-результат, который система сможет адекватно прочитать.
3. Понятный ответ: Если ошибка долетает до интерфейса, пользователь не должен видеть
Unexpected variable или NullPointerException. Ему нужно выдать адекватный статус: «Сервис временно недоступен, попробуйте позже».Исключение vs Валидация
Нужно четко разделять, где нам нужен
Try/Catch, а где достаточно обычного if. Try/Catch предназначен для *исключительных* ситуаций: диск переполнен, база данных ушла в ребут, отвалился внешний шлюз.Если же вы используете этот блок для валидации формы — это архитектурная ошибка. Ошибка пользователя, который ввел буквы в поле для номера телефона — это штатный сценарий, а не катастрофа. Не заставляйте компилятор прыгать через исключения там, где работает обычная бизнес-логика.
Ставь 🔥, если теперь будешь пользоваться try/catch осознанно. А если остались вопросы или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК | ВЕБМастер