Try...catch everywhere

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

Но я сознательно выбрал не "идеологически правильный", а практически эффективный подход - try...catch everywhere. Цель: создать единый, предсказуемый подход к тому, как ошибки двигаются через слои приложения. Суть: каждый публичный метод сервисного слоя должен быть обернут в try...catch, даже если внутри catch выполняется только rethrow.

💡 Что это нам дает:

1. Явность и предсказуемость. Даже если сервис пока не обрабатывает ошибку, наличие try...catch явно сигнализирует, что метод может завершиться исключением. Это создаёт консистентный паттерн по всей кодовой базе. 2. Простота масштабирования. Если позже появится необходимость добавить логирование, маппинг, retry или аналитику - это можно сделать без изменения структуры метода. 3. Безопасное пробрасывание. Использование rethrow, а не throw e сохраняет оригинальный стек вызовов. 4. Единый визуальный стандарт. При чтении кода сразу видно, где граница возможных ошибок и где они могут быть перехвачены.

⚠️ При этом мы зафиксировали следующие договоренности:

1. Блок catch всегда должен содержать rethrow. Иначе ошибка будет проглочена, и дебаг станет невозможным. 2. Никаких catch (e) {} без rethrow или обработки. Это считается ошибкой проектирования. 3. Если в будущем добавляется логика обработки, она должна быть добавлена внутрь уже существующего блока catch, а не вокруг метода.

В командах, где дисциплина обработки ошибок ещё не выстроена, формальное правило всегда оборачивать в try...catch + rethrow действительно работает как “архитектурная страховка”. Когда же дисциплина обработки ошибок в команде вырастет, можно будет говорить об ослаблении правила - оставлять try...catch только там, где ошибка фактически обрабатывается (маппинг, логирование, очистка ресурсов).

Любое архитектурное решение - это не догма, а ответ на конкретные условия: состав команды, зрелость процессов, технический долг. Когда команда растёт, правила и подходы тоже эволюционируют. И задача старших инженеров - не просто “знать, как правильно”, а понимать, когда и зачем применять то или иное решение.

Путь к инженерной зрелости (и личной, и командной) всегда начинается не с идеалов, а с системности.