Какая конструкция может использоваться вместе с try-catch в JavaScript
Что проверяют
Базовое знание синтаксиса и то, как вы строите обработку ошибок в реальном фронтенде. Следом обычно спрашивают, что будет с return в finally и как ловить ошибки асинхронного кода и компонентов.
Как отвечать
С try/catch используется finally, а рядом всегда стоит throw. Разложите по ролям:
finally: выполняется в любом случае, в том числе послеreturnвtry. Типичный пример:setLoading(false)после запроса, чтобы спиннер не завис при ошибке;throw: выбрасывает ошибку. Для своих случаев удобно наследоваться,class HttpError extends Error, а вcatchразбирать черезinstanceof. Опцияcause(ES2022) сохраняет исходную ошибку при переупаковке;catchбез параметра:catch { }разрешён с ES2019;try...finallyбезcatchтоже валиден: ошибка уйдёт выше, а очистка выполнится.
Порядок выполнения, который любят проверять: если в finally есть return, он перекрывает и результат try, и выброшенное исключение. Поэтому значения из finally не возвращают.
С асинхронным кодом try/catch работает только вместе с await. Без него ошибку ловят методом .catch(), а общую очистку делают в .finally(). Неперехваченные отказы промисов видны в событии unhandledrejection на window, туда обычно подключают отправку в систему мониторинга ошибок.
Если в стеке React, упомяните error boundary: он ловит ошибки рендера дочерних компонентов, но не ловит ошибки в обработчиках событий и в асинхронном коде, там по-прежнему нужен try/catch. В Next.js App Router эту роль играет файл error.tsx сегмента.
Где спотыкаются
Оборачивают в try/catch вызов setTimeout или промис без await и считают, что ошибка внутри будет поймана.
Глотают ошибку пустым catch или одним console.log. Пользователь видит зависший интерфейс, а мониторинг ничего не получает.
В TypeScript обращаются к error.message как к гарантированному полю. При strict переменная в catch имеет тип unknown (флаг useUnknownInCatchVariables), а бросить могли и строку, поэтому сначала нужна проверка error instanceof Error.