v9.4 ErrorBoundary catching errors caught by a child ErrorBoundary

[shrugs]

on v9.4 with the new ErrorBoundary, i'm seeing it catch errors that are being handled by a child ErrorBoundary (using react-error-boundary)

i assumed this would only happen if my custom error boundary throws during its render function after componentDidCatch, but it's not (otherwise react would unmount the entire tree in production, which it isn't).

is this expected behavior?

[Timer]

Could you explain the behavior you're seeing more? I'm not sure I understand.

The overlay will always display on an unhandled error, even if you have an error boundary. You can dismiss this overlay to view your error boundary, but the overlay will make you aware of the bug with a quick way to access the source code and fix it.

[pveyes]

Is it possible to display the overlay only if the error is not caught by nearest error boundary? I was surprised to see that my error boundary get overlayed and I thought for a second that mine was not working

Context: I'm working on network error boundary which handled API error from child using Suspense so it uses throw

[Timer]

No, this is not possible. Your code should gracefully handle API errors and not rely on an Error Boundary for "known" UI state.

The React documentation details using them for crashed trees.

[Timer]

Also, please be aware that using <Suspense> for data fetching is currently not supported by React, and will likely break in the future.

See their docs:
https://reactjs.org/docs/react-api.html#reactsuspense

Today, lazy loading components is the only use case supported by <React.Suspense>.

https://reactjs.org/docs/concurrent-mode-suspense.html

Suspense for Data Fetching is a new feature that lets you also use to declaratively “wait” for anything else, including data.
[snip]
This page describes experimental features that are not yet available in a stable release. Don’t rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React.

[pveyes]

I understand the risk of using experimental features, I'm just thinking of how in the future using error boundary to handle suspense error will probably be a common pattern (I could be wrong). If that's the case, having 2 error boundary showed on the screen might surprise some people.

I've talked with my colleagues and considering this is a dev only overlay it's fine so it's not really a big deal.

Your code should gracefully handle API errors

I did, in my case I'm handling network issue (offline, blocked by adblock, etc) when calling API. My error boundary renders retry button so people can recover. I think this is valid use case. The only thing that's different with "normal" is that I'm using Suspense so the error is handled using error boundary

[shrugs]

@Timer i didn't realize that errorboundaries should only be used for unexpected errors that would otherwise crash a react tree.

sounds like this is expected behavior, and that makes sense to me. here's an example project demonstrating the behavior (run in development), though it sounds like we're on the same page. https://github.com/shrugs/error-boundary-test

---

my use-case around catching known errors with errorboundaries is to synchronously render errors that would otherwise make the entire page unusable (not found, permission denied, rate limited, etc), which works well with both ssr and csr.

is there a best practice around handling app-level errors that's compatible with ssr that you can point me towards? for context, i'm using apollo-client, and these errors can arise during an ssr pass during getDataFromTree or normal csr.

the pattern i've seen people use with next frequently is a page HOC that checks for props and then renders the fallback if there was an error in getInitialProps, but as far as i've tried that pattern doesn't play well with apollo, since the errors are not actually thrown in getInitialProps and are surfaced in the component itself. one also does not want to globally catch every apollo error, since error handling is super contextual between components. in my app only errors fetching the top-level resources that would block further interaction with the app should be caught like this and all of the other errors are handled within their respective components.

to handle that behavior I was previously using a react context to share some state:

const [, setGlobalError] = useContext(GlobalErrorContext)

const {data, loading, error} = useQuery(...)
useIsomorphicLayoutEffect(() => {
  if (error) setGlobalError(error)
}, [error])

(with an error-boundary-like component that looks like)

function ChildrenOrGlobalError({ children }: PropsWithChildren<{}>) {
  const [error] = useContext(GlobalErrorContext)
  if (error) return MyFallbackComponent({ error });
  return children;
}

but because effects aren't executed during ssr, we get a single render of the component tree before the fallback component takes over

any thoughts?

[flybayer]

@Timer I also was very confused by how Next.js 9.4 is handling errors.

Even when you have a custom ErrorBoundary, the Next.js error overlay says "Unhandled Runtime Error" which is very confusing because I did indeed handle the error.

Your code should gracefully handle API errors and not rely on an Error Boundary for "known" UI state.

Do you have some inside information beyond what's public on how error handling will be used for data fetching? Because the latest React suspense for data fetching docs on error handling indicate the opposite of what you said.

Here's the example they have:

function ProfilePage() {
  return (
    <Suspense fallback={<h1>Loading profile...</h1>}>
      <ProfileDetails />
      <ErrorBoundary fallback={<h2>Could not fetch posts.</h2>}>
        <Suspense fallback={<h1>Loading posts...</h1>}>
          <ProfileTimeline />
        </Suspense>
      </ErrorBoundary>
    </Suspense>
  );
}

They are using an ErrorBoundary to catch any type of data loading error. Additionally, the documentation indicates that we should be using error boundaries judiciously, just like a normal try/catch.

My use case:

I'm using react-query for data fetching hooks all throughout the app in suspense mode.

The data fetching hooks can throw a few types of errors like AuthenticationError, AuthorizationError, and ItemNotFound.

Then we have one or more error boundaries throughout the app to handle these. For example, we can have a top level error boundary in _app that can render a login screen in response to an AuthenticationError. This is a really nice pattern.

Here's what I would like to see if the error was handled by a custom error boundary:

1. Hide the error overlay by default (user can then click on the small error indicator see it if they want)
2. Change "Unhandled Runtime Error" to "Handled Runtime Error"

[flybayer]

@timneutkens are you open for PRs to solve this issue?

Here's my latest request:

1. Show the error overlay by default only for dev specific errors like compilation errors
2. Hide the error overlay by default for all other errors like AuthenticationError etc if they caught by an error boundary.
3. In the overlay change "Unhandled Runtime Error" to "Handled Runtime Error" if the error was caught by an error boundary (because current verbiage is super confusing and makes you think your code is wrong when it isn't)

[kitze]

@flybayer this makes so much sense

[svobik7]

@flybayer's solution seems like the best approach for me, here! It is really annoying to get ErrorOverlay for handled errors.

[flybayer]

Here's the sibling thread to this for the same issue in Create React App, and Dan Abramov's suggested solution (which is almost exactly like what I last proposed)

facebook/create-react-app#6530 (comment)

[jackholt44]

another good reference on the topic: https://kentcdodds.com/blog/use-react-error-boundary-to-handle-errors-in-react

[NMinhNguyen]

Just stumbled upon this myself and after some digging this is due to

next.js/packages/react-dev-overlay/src/client.ts

Line 53 in c64005f

window.addEventListener('error', onUnhandledError)

and https://stackoverflow.com/a/57200935. @flybayer mentions in facebook/create-react-app#6530 (comment) that deleting error.stack works which would be explained by

next.js/packages/react-dev-overlay/src/client.ts

Line 9 in c64005f

if (!error || !(error instanceof Error) || typeof error.stack !== 'string') {

[TriStarGod]

Does that mean this issue is present only during dev?

[CapsAdmin]

I spent some time with this as well. Despite what the error box says, it's handled by my code and this only happens during development.

This was a quick and dirty workaround for my use case specifically.

if (process.env.NODE_ENV !== "production" && globalThis.window) {
  // prevent handled runtime errors from showing up in the error overlay

  const oldAddEventListener = window.addEventListener;

  try {
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    const client = (require as any)(
      "next/dist/compiled/@next/react-dev-overlay/dist/client"
    );
    client.unregister();
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    window.addEventListener = (type: any, listener: any) => {
      if (type == "error") {
        oldAddEventListener(type, (e) => {
          if (e.message && e.message.includes("usePromise")) {
            return;
          }

          listener(e);
        });
      } else {
        oldAddEventListener(type, listener);
      }
    };
    client.register();
  } finally {
    window.addEventListener = oldAddEventListener;
  }
}

I'm not sure about this but it seems that by throwing errors during rendering the error event will be emitted regardless independently from an error boundary.

If the order is preserved, so for example an error boundary catches it before it's emitted as an event; the best solution I can only think of is some function we can call during development that takes an error and blacklists it.

import { MarkErrorHandled } from "next/dev-overlay"
...
static getDerivedStateFromError(error: Error): ErrorState {
    MarkErrorHandled(error)
    return {
        error
    }
}

I'd avoid mutating or extending the error object.

[bstro]

Is this still an issue w/ Next 13 or are there other ways to handle this kind of situation? I'm running into this same behavior; I am wrapping a component hierarchy in a handled error boundary; within the boundary tree, there is a component that can throw an error; if/when the error is thrown, I see a next.js dev-mode-overlay instead of my expected UI.