Стратегия обработки ошибок в сервисе
Вопрос
Как вы организуете обработку ошибок в бэкенд-сервисе на ASP.NET Core?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Исключения для неожиданного, результат (Result, TryX) для ожидаемых бизнес-ошибок
Не глотать исключения: catch только там, где можно обработать или добавить контекст
throw; вместо throw ex, оборачивание с InnerException
Глобальный обработчик: IExceptionHandler и ProblemDetails, маппинг в HTTP-статусы
Структурное логирование с корреляционным id, без утечки деталей клиенту
Повторы и Polly для временных ошибок внешних сервисов
Что могут спросить следом
- Где граница между «бросить исключение» и «вернуть ошибку»?
- Что вы отдаёте клиенту при 500?
Разбор
Делю ошибки на два вида. Ожидаемые бизнес-ситуации, например «товар закончился» или «неверный промокод», это часть контракта: возвращаю результат с ошибкой, и контроллер превращает его в 409 или 422. Неожиданные ситуации, баги и сбои инфраструктуры, идут исключениями.
Ловлю исключение только там, где могу что-то сделать: повторить, обернуть с контекстом, освободить ресурс. Если пробрасываю, то throw;, чтобы не потерять стек, или новое исключение с innerException.
Наверху стоит глобальный обработчик: в .NET 8 это IExceptionHandler плюс AddProblemDetails. Он логирует исключение структурно, с trace id, и отдаёт клиенту ProblemDetails без стека и деталей. Валидация входных данных возвращает 400 с перечнем полей. Для временных ошибок HTTP и базы использую политики повторов с экспоненциальной задержкой через Polly или встроенный resilience-пакет Microsoft.Extensions.Http.Resilience.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.