Был ли опыт создания обработчиков исключений в веб-приложениях

Что проверяют

Делали ли вы централизованную обработку ошибок сами и понимаете ли, какие исключения до неё не доходят. Следом спрашивают, какой формат ответа вы отдавали клиенту и как отличали ошибки клиента от сбоев сервера.

Как отвечать

Нужен рассказ о своём проекте: стек, какие ошибки были, что вы сделали, что изменилось. Каркас для Spring Boot:

• глобальный обработчик: класс с @RestControllerAdvice и методами @ExceptionHandler под конкретные типы. Удобно наследоваться от ResponseEntityExceptionHandler, он уже обрабатывает стандартные ошибки Spring MVC;
• формат ответа: с Spring 6 и Boot 3 есть ProblemDetail по RFC 9457 (бывший RFC 7807), включается свойством spring.mvc.problemdetails.enabled. Один формат для всех ошибок плюс свой code для фронтенда;
• маппинг: доменные исключения вроде OrderNotFoundException на 404, MethodArgumentNotValidException на 400 со списком полей, всё непредвиденное на 500 без деталей;
• логирование: 4xx на WARN или ниже, 5xx на ERROR со стектрейсом, traceId в MDC и в теле ответа, чтобы по жалобе найти запись в логах;
• что advice не ловит: исключения в фильтрах, включая Spring Security. Для них AuthenticationEntryPoint и AccessDeniedHandler, в WebFlux свой WebExceptionHandler;
• тесты: MockMvc или WebTestClient на каждый тип ошибки с проверкой статуса и тела.

Результат описывайте своими цифрами: насколько ускорился разбор инцидентов, стало ли меньше обращений в поддержку. Если вы работали только с готовым обработчиком, честно скажите это и объясните, как он устроен и что бы вы в нём поменяли.

Где спотыкаются

Отдают клиенту e.getMessage() или стектрейс. Это утечка внутренностей, от имён таблиц до версий библиотек.

Ловят Exception в каждом контроллере через try/catch и возвращают 200 с полем error. Мониторинг по статусам такие сбои не видит.

Логируют исключение и тут же пробрасывают его выше, где его логируют снова. Одна ошибка оставляет в логах три одинаковые записи.