Что такое проваливание промисов (Promise rejection) в JavaScript

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

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

Как отвечать

Промис отклоняется в трёх случаях: внутри исполнителя вызван reject; в обработчике then или в теле async-функции выброшено исключение; отклонился промис, возвращённый из цепочки. Обработчик ловит только то, что случилось выше по цепочке.

Ключевое для браузера: fetch отклоняется лишь на сетевом сбое, обрыве или запрете доступа, а ответ с кодом ошибки для него совершенно штатный результат.

const res = await fetch(url, { signal });
if (!res.ok) throw new Error(`HTTP ${res.status}`);

Дальше назовите инструменты: catch в конце цепочки, try и catch вокруг await, finally для снятия индикатора загрузки, allSettled, когда нужны все результаты, и глобальный слушатель необработанных отклонений, чтобы потерянные ошибки доезжали до мониторинга, а не только до консоли.

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

Уверены, что ответ сервера с кодом ошибки приводит к отклонению fetch, и пишут обработчик, который ловит один обрыв сети. Проверка признака успешности ответа обязательна, иначе приложение спокойно разбирает страницу ошибки как данные.

Передают обработчик вторым аргументом then и ждут, что он поймает ошибку из соседнего обработчика успеха. Не поймает, он видит только пришедшее сверху. По той же причине бесполезен catch, поставленный в начале цепочки.

Теряют отклонения в групповых операциях: all завершается на первом отказе, остальные промисы остаются без обработчика и всплывают как необработанные. И не отделяют отмену запроса от настоящей ошибки, отчего мониторинг заполняется шумом при каждом уходе со страницы.