Error Boundaries for Data Fetching Failures

The plain-language idea

A React error boundary catches errors thrown while rendering — including errors thrown in lifecycle methods and constructors of the class components below it in the tree. That's a narrower guarantee than it sounds like. An error inside an async function, or inside a .catch() handler attached to a fetch call, is not a rendering error. It happens on its own schedule, outside the render pass the boundary is watching, so the boundary never sees it. Left alone, that failure either turns into an unhandled promise rejection or gets swallowed by whatever catch block happened to be nearby — the user sees nothing, or sees stale data forever.

For an error boundary to actually catch a data-fetching failure, the failure has to be re-surfaced during render. Two ways that happens in practice:

• Manual re-throw. A data-fetching hook stores the caught error in state, and on the next render, checks that state and throws the error synchronously as part of the render function itself. That throw happens during render, so a boundary above it catches it normally.
• Library-native throw-to-boundary support. Some data-fetching libraries have a mode built specifically for this — when a request fails, instead of just returning an error object for the component to check, they throw it back into the render tree so the nearest boundary catches it automatically, without hand-written re-throw logic.

Either way, the mechanism is identical to what makes render-time suspense-style loading work: an async result gets converted into something synchronous and throwable, timed to happen during render.

See it in a real thing: a hook that re-throws on render

function useUserProfile(userId: string) {
  const [state, setState] = useState<
    { status: "loading" } | { status: "error"; error: Error } | { status: "success"; data: Profile }
  >({ status: "loading" });

  useEffect(() => {
    let cancelled = false;
    fetch(`/api/users/${userId}`)
      .then((res) => {
        if (!res.ok) throw new Error(`Request failed: ${res.status}`);
        return res.json();
      })
      .then((data) => !cancelled && setState({ status: "success", data }))
      .catch((error) => !cancelled && setState({ status: "error", error }));
    return () => {
      cancelled = true;
    };
  }, [userId]);

  // The re-throw: this runs during render, not inside the async chain above.
  if (state.status === "error") {
    throw state.error;
  }

  return state;
}

function ProfileCard({ userId }: { userId: string }) {
  const state = useUserProfile(userId);
  if (state.status === "loading") return <Spinner />;
  return <div>{state.data.name}</div>;
}

Wrapping ProfileCard in an error boundary now works, because the failure the hook caught in a .catch() gets converted into a synchronous throw the very next time the component renders. Without that last if block, the boundary sits there doing nothing while the error state quietly updates underneath it.

What people usually miss

Watch out

• Catching an error in a .catch() handler does not make an error boundary see it. The boundary only watches the render pass — an error handled entirely inside async code never touches render unless something explicitly re-throws it there.
• An unhandled promise rejection is a real, common silent-failure shape. Skip the re-throw and skip a fallback UI, and a failed fetch can end up logged to the console (if that) while the screen just shows a permanent spinner or stale content.
• One error boundary per page is barely better than none. The value of a boundary comes from scoping it around one independently-failable unit, so a failure in one widget doesn't erase everything else on the page that was working fine.
• A re-thrown error still needs a real fallback, not a blank boundary. Catching the error and rendering nothing is only marginally better than the crash it replaced — the fallback should tell the user something actually failed and, where reasonable, offer a way to retry.

Why this matters in interviews

"Where would you put your error boundaries, and how would a failed API call actually reach one?" tests whether a candidate understands error boundaries as a render-time mechanism specifically, not a generic try/catch for anything that can go wrong in a component.