Что такое finally в Promise

Promise.prototype.finally добавляет действие на момент, когда Promise перешел в конечное состояние. Это состояние может быть fulfilled или rejected. Поэтому короткий ответ такой: finally нужен для кода, который должен выполниться в любом случае.

Здесь легко сказать лишнее. finally не получает аргументы. Внутри callback вы не знаете напрямую, что пришло: данные или ошибка. Поэтому туда не кладут бизнес-логику обработки результата.

Для фронтенда вывод простой. Loader, временная блокировка кнопки, технический cleanup и сброс локального флага могут жить в finally. Показ ошибки, парсинг ответа и обновление данных должны быть в then, catch или в try/catch при async/await.

finally возвращает новый Promise. Если callback завершился без ошибки, новый Promise повторит исходный результат. Успешное значение останется успешным значением. Причина reject останется причиной reject.

Promise.resolve("data")
  .finally(() => "ignored")
  .then((value) => {
    console.log(value); // "data"
  });

В этом примере строка "ignored" не попадет в следующий then. Это частая ловушка: обычный return из finally не заменяет данные.

Но если callback падает, результат меняется:

Promise.resolve("data")
  .finally(() => {
    throw new Error("cleanup failed");
  })
  .catch((error) => {
    console.log(error.message); // "cleanup failed"
  });

Здесь исходное "data" потеряно, потому что ошибка в cleanup стала новой ошибкой цепочки. В реальном коде cleanup лучше делать простым и безопасным.

На интервью полезно показать не только определение, но и критерий выбора. Вопрос не в том, можно ли написать finally. Вопрос в том, какую ответственность вы в него кладете.

Порядок в цепочке тоже важен. Если написать promise.finally(cleanup).catch(handleError), cleanup выполнится до обработки ошибки. Если написать promise.catch(handleError).finally(cleanup), сначала сработает обработка ошибки, а потом cleanup.

Оба варианта могут быть правильными. Сильный ответ звучит так: я ставлю finally там, где мне нужен общий cleanup относительно остальных обработчиков. И не использую его как скрытый catch.

Типичный пример: запрос к API, где кнопку нужно разблокировать после любого результата.

setLoading(true);

fetch("/api/profile")
  .then((response) => {
    if (!response.ok) {
      throw new Error("Request failed");
    }

    return response.json();
  })
  .then((profile) => {
    setProfile(profile);
  })
  .catch((error) => {
    setError(error);
  })
  .finally(() => {
    setLoading(false);
  });

Этот пример хорош тем, что роли разделены. Проверка response.ok и парсинг живут в обработке результата. Ошибка живет в catch. Общий флаг загрузки снимается в finally.

Но пример безопасен только для одиночного запроса на живом экране. Если пользователь быстро меняет id, фильтр или вкладку, старый запрос может завершиться позже нового и вызвать setLoading(false) не вовремя. Если компонент уже размонтирован, старый ответ может попытаться обновить неактуальное состояние. На практике лучше отменять запрос или проверять, что ответ все еще относится к текущему экрану.

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

const requestId = useRef(0);

async function loadUser(id) {
  const currentRequest = requestId.current + 1;
  requestId.current = currentRequest;
  setLoading(true);

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

    if (!response.ok) {
      throw new Error("Request failed");
    }

    const user = await response.json();

    if (currentRequest === requestId.current) {
      setUser(user);
    }
  } catch (error) {
    if (currentRequest === requestId.current) {
      setError(error);
    }
  } finally {
    if (currentRequest === requestId.current) {
      setLoading(false);
    }
  }
}

Здесь finally все еще отвечает за cleanup. Но cleanup выполняет setLoading(false) только для последнего актуального запроса. Так UI защищен от старого ответа, который мог бы перезаписать данные или погасить loader для нового запроса.

Когда запрос привязан к компоненту, одного finally мало. Нужно отменить запрос при смене зависимости или размонтировании. Иначе ответ может прийти уже на другой экран.

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

  setLoading(true);

  fetch(`/api/users/${id}`, { signal: controller.signal })
    .then((response) => {
      if (!response.ok) {
        throw new Error("Request failed");
      }

      return response.json();
    })
    .then((user) => {
      setUser(user);
    })
    .catch((error) => {
      if (error.name !== "AbortError") {
        setError(error);
      }
    })
    .finally(() => {
      if (!controller.signal.aborted) {
        setLoading(false);
      }
    });

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

Здесь cleanup эффекта отменяет старый запрос. finally все еще выполняется, но проверка signal.aborted не дает отмененному запросу менять состояние загрузки. Так UI не мигает старым loader и не показывает ошибку от штатной отмены.

Самая важная ловушка: finally не делает ошибку обработанной. Если цепочка была rejected, после finally она останется rejected, пока вы не обработаете ее в catch или не поймаете через try/catch.

fetch("/api/profile")
  .finally(() => {
    setLoading(false);
  });

// Плохо: при сетевой ошибке нет catch, ошибка уйдет как необработанный reject.

Что сломается в UI: loader исчезнет, но пользователь не увидит понятный error state. Ошибка может попасть только в консоль или глобальный обработчик. А экран останется пустым или со старыми данными.

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

С async/await та же идея часто выглядит через обычный try/catch/finally. Для ответа на интервью полезно связать эти две формы.

async function saveForm(values) {
  setSubmitting(true);

  try {
    const response = await fetch("/api/form", {
      method: "POST",
      body: JSON.stringify(values),
    });

    if (!response.ok) {
      throw new Error("Save failed");
    }

    return await response.json();
  } catch (error) {
    showError(error);
    throw error;
  } finally {
    setSubmitting(false);
  }
}

Здесь finally не обязан знать, сохранилась форма или нет. Он только возвращает UI из состояния отправки. Если в finally бросить новую ошибку, она так же заменит исходную ошибку или успешный результат функции.