Add option to disable the error boundary or bubble "outside of the router"

[cbn-falias]

Whilst the errorElement might be a nice addition, it's quite inconvenient when having custom ErrorBoundaries in place or using one from another package like the AppInsightsErrorBoundary.

An app-wide ErrorBoundary can't be used anymore because react-router will always catch it beforehand.
So when having components outside of the router it basically requires two implementations (the "default one" and one using useRouteError)

Crude suggestion

<RouterProvider router={router} disableErrorBoundary={true} />

Current workaround

Move the <RouterProvider> as high as possible and wrap the top-most route with the custom ErrorBoundary.

const Root = () => (<CustomErrorBoundary><Outlet /></CustomErrorBoundary>);
...
<Route path="/" element={<Root />}>

[alexrecarey]

Not thowing the error means that in development my app does not fail and send the stack trace to the terminal. This means that all of the IDE work that has gone into processing stack traces and linking to the correct sites is useless. Am I doing something wrong? Is this really the intended behaviourin development? How does everybody else use react-router while they develop? Just watching the errors printed on the html?

[gustaff-weldon]

I second the request.
We already have an app-level error boundary in place, which apart from showing a nice error message to users, it also does report the issue to us.

We cannot use it atm, as the routes are intercepting the errors displaying default ErrorBoundary of the RR.

We have tried adding a top level error boundary via:

  const renderApp = (): ReactNode => (
    <>
        ... lost of context providers
             <ModulesRootContainer env={environment} />
    </>
  );

  const router = createBrowserRouter([
    {
      path: '/*',
      element: renderApp(),
      ErrorBoundary
    }
  ]);

But it does not work, we are still seeing the default handler on routes in modules that are not direct children of the above browser router (they are rendered as <Routes><Route> inside modules routed from ModuleRoutes).
We have tried wrapping the above modules container with the <ErrorBoundary>, but it didn't help. It looks like the error never reaches it and it is handled by one of the child routes with the default RR boundary.

While I appreciate the default error handling, there should be a way to disable that and wrap app in our own boundary. At the moment is is more of a hindrance than aid.

[jasikpark]

are you using "useRouteError" in your error boundary? the naming seems kinda confusing since you need to use that hook rather than a standard error boundary setup

[cbn-falias]

@jasikpark Well, that's exactly the big issue with that. I want/need to use the "standard error boundary setup" but the current react-router doesn't allow me to do that.

[gustaff-weldon]

Exactly, plus, when you do not use one huge <Routes />, bubbling of errors to the top-most ErrorBoundary just does not work.

I honestly cannot recall an upgrade of a lib that was getting in my way so much as React Router v6 does.

[jancajthaml]

Just re-throw the error.

import { createBrowserRouter, useRouteError } from "react-router-dom";

...

const BubbleError = () => {
  const error = useRouteError();
  throw error;
};

...

const router = createBrowserRouter([
  {
    path: "*",
    element: <Root />,
    errorElement: <BubbleError />,
  },
]);

...

This seems to work properly

[cbn-falias]

It's another workaround but not a solution.

• I am required to use the useRouteError which may or may not modify the error object
• I have no direct access to componentDidCatch(error, errorInfo) {}
• If I'm not mistaken, you get every error twice because it's basically only an ErrorBoundary in an ErrorBoundary

[brophdawg11]

This feels like the proper approach to bubble outside the router to me. To answer your questions:

• useRouteError does not touch the thrown value - you'll get exactly what you threw
• Accessing the errorInfo from componentDidCatch is on the radar
• Can you elaborate on this point? If you mean "logged twice" - you should have control over that once we land the API from [Feature]: Expose `errorInfo` from the `ErrorBoundary` #9881

[cbn-falias]

Those points should only be a quick list of things I have to consider/handle because of this opinionated error handling which I don't want or need.
With an option to disable the boundary all points are gone.
By extending the API they aren't.

---

Regarding the last point: It's been a while but I think it was related to a global error listener (window.onerror done by AppInsights). I have to distinct/merge the "bubble error" and the "actual error".

[coleturner]

It's not so easy to just "rethrow the error." I feel React Router is very opinionated about Route composition, in order to support a variety of use cases. When migrating from declarative routing to data routing, in my use case it would require significant refactoring. It would be incredibly helpful if we had more configuration of the default behavior.

I would like to see the ability to also configure the Default Error Boundary that's used when in Data mode.

function MyAppDefaultErrorBoundary() {
   const error = useRouteError();
   if (error) {
      throw error;
   }
  // ...
}

const router = createBrowserRouter([
  {
    path: "*",
    element: <Root />,
    errorElement: <RootErrorBoundary />,
  },
],  { defaultErrorBoundary: MyAppDefaultErrorBoundary });

This would immediately solve problems I am running into with route composition, and I feel like it could help similar issues noted in this thread.

[bautistaaa]

@ryanflorence we demand justice

[kenny-lu-hl]

Upvote. Would like to see this be implemented.

[rookie-luochao]

Support this configuration and hope to implement it soon, It is now implemented through hacks

[emberist]

This would be helpful! Need it as we use react-query and react-error-boundary together

[toridyar]

Upvote. We have global error handling via a common component library used by multiple apps/teams, and we all now have to implement a custom "hack" individually to handle errors at each route also

[IanVS]

This is also a problem when using Storybook with their test-runner, because stories with errors no longer fail tests.

[brophdawg11]

Have folks tried the solution proposed above to just re-throw from a root level boundary to get it outside the router? #10166 (comment)

const router = createBrowserRouter([
  {
    path: '/'
    Component: Root,
    ErrorBoundary: () => { 
      throw useRouteError();
    },
  },
]);

There is a separate concern of being able to gain access to the errorInfo parameter of componentDidCatch, which is on the radar and tracked in #9881.

[cbn-falias]

Built-in error handling is a feature that we believe makes sense for the vast majority of apps

Yes I agree, but why should exactly a client side router be the one who enforces this?
The react-router is definitely a major building block in every app but it's not the only one.

I don't see the benefit of a separate config flag to be used by a small contingent of apps over adding those lines in those specific cases.

When I compare this to #9881 I don't really get this argument.
I am pretty sure that solely providing the errorInfo addresses an even "smaller contingent of apps".

This proposal is still one of the most upvoted ones and people commented that it interferes with other popular packages.
Aren't those enough reasons that it should be rated a lot higher than #9881? 🤔

[brophdawg11]

It's not that it definitely won't be considered - Michael and Ryan do the roadmap reviews so they may still review it and make a more official call. I'm giving you my opinion and a way to solve your issue today. From a reading of all of the comments on this proposal, I don't see a single scenario that wouldn't be solved by re-throwing from a root boundary. I asked "have folks tried" specifically because I think this solves all of the presented use-cases, and if not, a reproduction of the use-case would be helpful. "I don't want to add those lines of code" is different from "I can't solve this problem". Meanwhile, you can always use patch-package to remove the error boundary for your project.

As far as the upvotes, IMO this proposal is flawed as the primary premise is inaccurate:

An app-wide ErrorBoundary can't be used anymore because react-router will always catch it beforehand

An app-wide ErrorBoundary can be used with 3 lines of code as recommended in #10166 (comment) and shown above, and my hunch is that most of the folks upvoting did not realize this solution was available to them. #9881 on the other hand is not possible today which is why I believe it is higher priority.

At this point I think we should agree to disagree. I'm not really interested in continuing to argue with you, so this will be my last comment on this thread 😄

[Slessi]

The rethrow works for me. I am curious though what the benefit of the errorElement feature here is.

I am under the impression that the below are equivalent:

const useErrorElement = {
  errorElement: <ErrorElement />,
  element: <Element />,
}

const wrapItUrself = {
  element: (
    <ErrorBoundary>
      <Element />
    </ErrorBoundary>
  )
}

The second version works (even now), but without needing knowledge of react-router features. I ask what is the value because I agree with what you said:

As library maintainers, we have to weigh the pros/cons of adding an option to configure every bit of functionality that every user requests against the documentation/testing/maintenanc

Only I feel like i'd take it a step further and question why this functionality should exist at all. It feels a bit out of scope of my expectations of a routing library, and the second version in my example isn't really more complicated or verbose. Could argue its simpler, since its vanilla react.

Maybe I am missing the problem this feature is trying to solve?

[brophdawg11]

@Slessi Great question! That type of approach works for render errors, but doesn't work for data errors. React Router needs to know which routes have error boundaries so it can bubble errors properly during the data phases. Your example above works at the React render phase, but the data phase is decoupled from rendering in RouterProvider.

Consider a route structure such as:

const router = createBrowserRouter([
  {
    path: '/a'
    loader: aLoader,
    Component: A,
    ErrorBoundary: Error,
    children: [{
      path: '/b'
      loader: bLoader,
      Component: B,
      children: [{
        path: '/c'
        loader: cLoader,
        action: aAction,
        Component: C,
      }]
    }]
  },
]);

One of the core tenants of the RouterProvider design is that we keep your components "happy path" so they don't have to handle error flows and loading states.

If you route to /a/b/c and cLoader throws an error - we need to be able to determine that that error is handled at the /a error boundary, and then we don't render B (since it won't be shown anyway) or C - and more importantly we can't render C because there is no data to provide for useLoaderData. If error boundaries are strictly handled at rendering time, then in order to bubble data errors such as this, you'd have to do a bunch of conditional logic to see if you got data or an error in C and then re-throw accordingly.

A more complex example is <Form method="post" action="/a/b/c">. If you submit to C and cAction throws - we bubble that to /a's Error as well and then we don't even bother calling bLoader or cLoader.

Without knowledge of whether or not a route has an error boundary we can't perform that logic. Interestingly enough, the underlying router is framework agnostic so it doesn't know about the react-specific errorElement/ErrorBoundary at all and only knows a boolean value of hasErrorBoundary

[jeremiah-snee-openx]

@brophdawg11 the work around still has disadvantages. The stack trace reported for the errors shows the errorElement/ BubbleError component as the source of the error and not where it was originally thrown.

[Joao-vi]

Hi everyone, this was my work arround to get access to error and info. Hope this help you guys

[acolchagoff]

We're struggling with this as well, we have an isomorphic web application that renders a serviceable html version of the page On initial load. Unfortunately the ErrorBoundary driven solutions above insist on re-rendering and replacing a usable page with a non-usable one. I would like to simply allow the error to run it's course. This way, the error will get picked up by our logging, hydration will fail, and the initial html will continue to be displayed to the user who will click on to the next page without knowing anything went wrong.

As library maintainers, we have to weigh the pros/cons of adding an option to configure every bit of functionality that every user requests against the documentation/testing/maintenanc

Only I feel like i'd take it a step further and question why this functionality should exist at all. It feels a bit out of scope of my expectations of a routing library, and the second version in my example isn't really more complicated or verbose. Could argue its simpler, since its vanilla react.

I agree with this take, error handling seems outside the scope of a router and would be extremely easy to implement, but in it's current state it forces itself on all users.

[peplocanto]

I think that this (partial) error handling feature doesn't adhere to the separation of concerns principle.
I want the flexibility to implement the routing feature using RRD and handle errors with the best option I see fit.
The rethrow workaround seems like a very 'meh' solution to me. I can take this a step further: in my opinion, it should be a tree-shakeable addon for those who want to use it, which I believe will be the minority of users.
My concerns are that this is not a real solution (acceptable in production), and it decreases performance due to the rethrow and unnecessary code included in the library.

[dchenk]

Part of what makes React Router's built-in error boundaries problematic is that we're forced into the re-throw hack so that we can use the root error boundary, which is typically where we install Sentry or the equivalent (an error reporting service).

If I split up my route config across a few files, I need to remember to add my re-throw component as the error boundary for each top-level route. Otherwise React Router's error boundary catches and swallows errors, so they're never reported to Sentry.

I think many thousands of apps using React Router are set up this way—i.e., with only an error boundary at the root.

[Azeirah]

I'm working on a legacy application. It's old and bad react code, I'm working on modernizing it.

There are literally hundreds of exceptions thrown all over the place. They're "normal". Despite these exceptions, the app works reasonably well; sorta.

However, I migrated from the legacy router to the browser router and now the app won't even render? We can't upgrade from an earlier version of react router to a newer one because suddenly react-router decided it wanted to decide when the app should or shouldn't render? This makes no sense.

Yes of course we intend to clean up the errors, but most of the errors are very inconsequential and would be nice to clean up like it would be nice to clean up the attic at home, not because fatal errors are occurring all over the place!

[brophdawg11]

I'm not sure I understand. Are you using BrowserRouter or RouterProvider?

[bagasmdputra]

I also faced the same issue. I upgraded the react-router and the legacy code is broken. The bad news is that some of the main business flow is interrupted. The code owner knew it usually produces a max rerender error in the console even though the business flow continues as usual. Still, because of this update, it is broken everywhere.

I use RouterProvider and from this issue, I recently learned that some eng prefers not to touch the legacy code. I will modernize it but it will be better if it doesn't broke an existing flow

[bagasmdputra]

sorry I've just rechecked the code, the router uses RouterProvider that was converted to BrowserRouter using createRoutesFromElements

[sarink]

It is not the responsibility of the router to catch errors.

I can see how this would be useful to people, so it's a nice addition, but it should be an opt-in feature. As other folks have said, if you upgrade your router, you should not expect to have it impact your app's global error handling code. Also, you might not even know! And how will you find out, if you're not getting error reports sent?!

...and my hunch is that most of the folks upvoting did not realize this solution was available to them.

So, if you have a highly upvoted issue and none of your users know the workaround available to them, don't you think that is evidence of a poor or unintuitive design?

I'm glad there's a simple workaround, but this decision making is disappointing.