The error boundary catches only the exceptions thrown by function components, therefore this exception will escape it since it happens in a separate function that is pushed to the call stack after the timeout is expired.

The same happens if you throw an error in an event handler, it will not get handled.

The React error boundary is a safe net only for errors that can break rendering.

i dont think i understand, how can i test the error.tsx or global-error.tsx files? i've updated that setTimeout to this (below) but it doesnt render these files still, it just renders the red error notification in the bottom left and in prod it does nothing

new Promise((_, reject) => {
  setTimeout(() => {
    reject(new Error('test'));
  }, 2500);
});

In production, it does nothing because nothing should be exposed to hackers. Also, check the event loop to understand the above answer.

Errors thrown during rendering of the component, such as

function Foo() {
  throw new Error(…)
  return <Bar />
}

are captured by error boundaries.

Errors thrown inside event handler or useEffect callbacks run separately from rendering. They do not crash the component and are not handled by the error boundary. You need to try/catch them.

In production error.tsx and global-error.tsx are still effective. In fact they do more things in prod mode than in dev mode where the default error overlay takes precedence.

In OP’s case it is just not a scenario where the error is handled by a boundary. OP can still open the browser console to see the error message in there.

I meant that when you deploy the application, sometimes errors occur that aren’t handled properly. Instead of the usual red error notification, you get a default white screen with a strange error code or hash in the middle. Only developers can use that code to identify the error. Or otherwise, as you mentioned, you can only see the details in the browser console.