Что принимает метод reject в Promise

У Promise есть два финальных состояния: fulfilled и rejected. reject(reason) переводит Promise в состояние rejected. Переданное значение становится причиной отклонения. Это значение обычно называют reason.

На интервью стоит сказать аккуратно: JavaScript не требует, чтобы reason был именно Error. Но если вы передаете строку или произвольный объект, вы сами отвечаете за то, как потом это обработать, залогировать и показать пользователю.

Хороший короткий ответ:

reject принимает один аргумент, причину отклонения Promise. Передать можно любое значение, но на практике лучше передавать Error или свой класс ошибки, чтобы не потерять stack и иметь единый формат обработки.

Значение из reject попадает в обработчик ошибок без преобразования. Если вы передали строку, в catch будет строка. Если передали Error, будет объект ошибки.

Promise.reject(new Error("Failed to load user"))
  .catch((error) => {
    console.log(error.message);
    console.log(error.stack);
  });

Promise.reject("Failed to load user")
  .catch((reason) => {
    console.log(reason); // строка, не Error
  });

Первый вариант лучше для приложения. Его проще обрабатывать одинаково во всех местах: можно прочитать message, отправить ошибку в мониторинг и сохранить стек вызовов. Второй вариант допустим для маленького примера, но в кодовой базе быстро приводит к проверкам вида typeof reason === "string".

На практике вопрос не в том, что разрешено. Важнее, какой контракт будет удобен вашему UI. Если компоненту нужно понять, что случилось, передавайте структурированную ошибку. Если это обычный результат, не маскируйте его под ошибку.

Плохой вариант: отклонить Promise строкой и потерять статус ответа.

async function loadUser(id) {
  const response = await fetch(`/api/users/${id}`);

  if (!response.ok) {
    return Promise.reject("Request failed");
  }

  return response.json();
}

На практике компонент не поймет, это 401, 404 или 500. В итоге UI может показать общий toast там, где нужно отправить пользователя на логин или показать состояние "пользователь не найден".

Безопаснее нормализовать ошибку.

class HttpError extends Error {
  constructor(message, { status, url }) {
    super(message);
    this.name = "HttpError";
    this.status = status;
    this.url = url;
  }
}

async function loadUser(id) {
  const response = await fetch(`/api/users/${id}`);

  if (!response.ok) {
    throw new HttpError("Failed to load user", {
      status: response.status,
      url: response.url,
    });
  }

  return response.json();
}

Здесь используется throw, но внутри async функции результат будет тем же для вызывающего кода: функция вернет rejected Promise. При этом ошибка сохранит тип, сообщение и статус.

Когда вы пишете await для Promise, который был отклонен через reject, управление переходит в catch. Поэтому при ответе можно связать Promise-стиль и async/await.

async function renderUser() {
  try {
    const user = await loadUser("42");
    return user.name;
  } catch (error) {
    if (error instanceof HttpError && error.status === 404) {
      return "User not found";
    }

    throw error;
  }
}

Практический вывод для фронтенда: обработчик должен не только вывести ошибку в консоль. Обычно он еще снимает loading, показывает fallback, делает rollback optimistic UI или решает, можно ли повторить запрос.

Во фронтенде rejected Promise не всегда значит аварийный сбой. Например, запрос мог быть отменен, потому что пользователь ушел со страницы или быстро ввел новый текст поиска. Если обработать отмену как обычную ошибку, UI покажет ложный toast, перетрет новые данные старым состоянием или оставит кнопку в loading.

Опасный вариант: любой catch переводит экран в ошибку.

async function submit(signal) {
  setLoading(true);

  try {
    await fetch("/api/profile", { signal });
  } catch (error) {
    setError("Не удалось сохранить профиль");
  } finally {
    setLoading(false);
  }
}

Если запрос отменили намеренно, пользователь все равно увидит сообщение об ошибке. Безопаснее отличить отмену от сбоя и оставить catch для реальной проблемы.

async function submit(signal) {
  setLoading(true);

  try {
    await fetch("/api/profile", { signal });
    setError(null);
  } catch (error) {
    if (error?.name === "AbortError") {
      return;
    }

    setError("Не удалось сохранить профиль");
  } finally {
    setLoading(false);
  }
}

На интервью это можно сформулировать так: значение из reject должно помогать UI принять решение. Настоящую ошибку показываем и логируем. Ожидаемую отмену обрабатываем тихо, но состояние загрузки все равно закрываем.

Ошибка в Promise почти всегда связана с состоянием интерфейса. Если вы отклонили Promise, но не обработали причину, пользователь может остаться со спиннером, заблокированной кнопкой или пустым экраном.

На интервью не ограничивайтесь фразой "reject принимает ошибку". Это звучит неполно, потому что по факту он принимает любое значение. Лучше показать оба уровня ответа: формальный контракт и хорошую практику.

Сильная формулировка:

reject принимает один аргумент, reason отклонения. Тип не ограничен, но я бы передавал Error или свой Error-наследник. Так catch получает нормальную ошибку со stack и контекстом, а UI может обработать разные сбои без догадок по строкам.

Если вас спросят про строку, не спорьте, что она запрещена. Скажите, что она допустима, но хуже для поддержки и наблюдаемости.