Как устроена обработка ошибок в приложении
Вопрос
Как вы организуете обработку ошибок во фронтенд-приложении: от запроса к API до того, что видит пользователь?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Слой API превращает ответы в типизированные ошибки (HttpError со статусом, сетевые, таймауты)
Ловим там, где можем обработать: повтор, отложенная запись, сообщение; остальное пробрасываем
Понятные сообщения пользователю, технические детали в логи
Error Boundary для ошибок рендера, `try/catch` в обработчиках и async-коде
Глобальные `error`/`unhandledrejection` и отправка в мониторинг (Sentry) с контекстом
`cause` при обёртке, без пустых `catch`
Что могут спросить следом
- Какие ошибки стоит повторять автоматически, а какие нет?
- Что не ловит Error Boundary?
- Как не заспамить мониторинг одинаковыми ошибками?
Разбор
Образцовый ответ: «Начинаю с клиента API: он превращает любой неуспех в понятный тип. HttpError со статусом и телом, отдельная ошибка сети, ошибка таймаута, ошибка отмены. Дальше правило: ловлю ошибку только там, где могу что-то сделать. Например, сетевую ошибку при сохранении черновика ловлю и ставлю запись в очередь, на 401 обновляю токен и повторяю запрос, а всё неизвестное пробрасываю. Пользователю показываю человеческое сообщение и действие: повторить, войти заново. Детали отправляю в лог. Для ошибок рендера ставлю Error Boundary на уровне страниц и крупных виджетов, чтобы падал кусок интерфейса, а не всё приложение. Он не ловит обработчики и асинхронный код, там обычный try/catch. Последняя линия: глобальные обработчики error и unhandledrejection, которые отправляют всё в Sentry с контекстом пользователя и версии. При обёртке ошибок передаю cause, чтобы не терять исходный стек. Пустых catch не допускаю».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.