Какие знаешь способы отслеживания и обработки ошибок

В ответе лучше сразу разделить два слова: обработка и отслеживание. Обработка отвечает за то, что увидит пользователь прямо сейчас. Отслеживание отвечает за то, как команда узнает об ошибке после релиза.

Коротко можно сказать так:

Я стараюсь ловить ошибку как можно ближе к месту, где могу принять правильное решение. Если это запрос, обрабатываю статус и сетевые ошибки. Если это React-рендер, использую Error Boundary для fallback UI. Если ошибка не была поймана локально, глобальные обработчики и monitoring помогают не потерять сигнал в production.

Такой ответ показывает систему, а не просто список инструментов. Это звучит сильнее, чем перечисление try/catch, console.error и Sentry без контекста.

На практике фронтенд обычно использует несколько уровней защиты. Локальный уровень нужен там, где понятен сценарий: форма, загрузка списка, сохранение настроек, оплата. В этих местах вы можете показать сообщение, не потерять состояние и дать повторить действие.

Уровень UI нужен, чтобы приложение не оставалось в вечном loading или пустом экране. Для React это состояние ошибки в компоненте, fallback, Error Boundary для части дерева и аккуратный rollback при optimistic update.

Глобальный уровень нужен как последняя сетка безопасности. Он не делает сценарий удобным сам по себе, зато помогает заметить в production необработанные исключения, ошибки загрузки ресурсов или promise без catch.

Частая ловушка на интервью связана с fetch. Он делает reject при сетевой ошибке, отмене запроса или похожей проблеме транспорта. Но HTTP-ответ со статусом 404 или 500 обычно придет как обычный response, поэтому его нужно проверить явно.

Плохой пример:

async function loadProfile() {
  const response = await fetch("/api/profile");
  return response.json();
}

Здесь ошибка сервера может попасть в код как будто это успешный ответ. Еще хуже, если UI уже очистил старые данные и остался пустым. Если такой вызов стоит в React-эффекте и параметр быстро меняется, старый ответ может перетереть новые данные.

Более безопасный вариант для функции загрузки:

async function loadProfile(profileId, { signal } = {}) {
  const response = await fetch(`/api/profile/${encodeURIComponent(profileId)}`, { signal });

  if (!response.ok) {
    throw new Error(`Profile request failed: ${response.status}`);
  }

  return response.json();
}

async function showProfile(currentProfileId) {
  setStatus("loading");

  try {
    const profile = await loadProfile(currentProfileId);
    setProfile(profile);
    setStatus("success");
  } catch (error) {
    setStatus("error");
    reportError(error, { route: "/profile" });
  }
}

В компоненте с загрузкой по параметру добавьте отмену. Это защищает от race condition и обновления состояния после размонтирования.

useEffect(() => {
  const controller = new AbortController();

  setStatus("loading");

  loadProfile(profileId, { signal: controller.signal })
    .then((profile) => {
      setProfile(profile);
      setStatus("success");
    })
    .catch((error) => {
      if (error.name === "AbortError") return;

      setStatus("error");
      reportError(error, { route: "/profile" });
    });

  return () => controller.abort();
}, [profileId]);

Ошибку в UI лучше делать не только видимой, но и доступной. Например, сообщение о неудачной загрузке можно отдать через role="alert" или связать с полем формы через aria-describedby. Тогда пользователь клавиатуры или скринридера тоже поймет, что произошло.

Error Boundary стоит упоминать аккуратно. Он полезен, когда часть интерфейса может упасть при рендере, но вы хотите сохранить остальное приложение живым. Например, можно обернуть виджет с графиком, сложный кабинет или область с данными от внешнего сервиса.

Минимальный пример:

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    reportError(error, { componentStack: errorInfo.componentStack });
  }

  render() {
    if (this.state.hasError) {
      return <p>Не удалось показать этот блок. Попробуйте обновить страницу.</p>;
    }

    return this.props.children;
  }
}

Важно сразу сказать ограничение. Error Boundary не ловит ошибку внутри обработчика клика, setTimeout или async-функции. Там нужна обычная обработка в самом сценарии.

Глобальные обработчики нужны не для того, чтобы весь код можно было писать без проверок. Это последний уровень, который помогает не потерять необработанные ошибки.

window.addEventListener(
  "error",
  (event) => {
    const target = event.target;
    const isResourceError = target && target !== window;

    reportError(event.error ?? new Error(String(event.message || "Resource load error")), {
      type: isResourceError ? "resource-error" : "window-error",
      source: isResourceError ? target.src || target.href : event.filename,
      line: event.lineno,
    });
  },
  true
);

window.addEventListener("unhandledrejection", (event) => {
  reportError(event.reason, {
    type: "unhandledrejection",
  });
});

Третий аргумент true нужен, если вы хотите поймать ошибки загрузки скриптов, картинок или CSS в фазе capture. Но даже такой код не чинит экран пользователя. Он только отправляет сигнал команде.

В продакшене важно добавить release, sourcemaps, route, breadcrumbs и безопасный user id. Без версии релиза и sourcemaps stack trace из минифицированного бандла часто мало помогает. Но не отправляйте токены, cookies, пароли, содержимое форм и полный payload запроса.

Хороший ответ можно собрать в 4 шага.

1. Сначала назвать локальную обработку: try/catch, .catch, проверка статуса ответа, состояние ошибки в UI.
2. Затем React-уровень: Error Boundary для ошибок рендера и fallback UI.
3. Потом глобальный уровень: error и unhandledrejection как последняя сетка безопасности.
4. В конце monitoring: Sentry, Rollbar или свой collector с фильтрацией данных и контекстом релиза.

Если хотите звучать практично, добавьте мысль про пользователя. Ошибка должна быть не только записана в лог, но и превращена в понятное состояние интерфейса. Это сразу отделяет зрелый frontend-подход от простого перечисления API.