How to prevent ReactDOM.render errors from bubbling when otherwise explicitly handled

Do you want to request a feature or report a bug?

This is a bug. Ordinarily, this would probably be considered a feature request. However, the stated purpose of the feature referenced below is being violated in certain environments.

What is the current behavior?

React 16+ surfaces an uncaught error during render, even when using componentDidCatch as designed or using try/catch around the render. As described in the comment above the related code, this is a convenience provided for developers using DevTools for debugging purposes. However, the convenience provided for development debugging is changing behavior in specs, causing failures for otherwise protected code paths, which goes against this statement from the comment description for the code:

But because the error happens in a different event loop context, it does not interrupt the normal program flow.

When the error occurs, a spec runner such as Mocha will fail the test with the uncaught error, then continue with the next test. After advancing, the second render of the component will complete and call the ReactDOM.render callback, which continues code from the already-failed test while a subsequent test is in progress. This pollutes the spec suite and leads to other issues that are not produced when using the Production version of React.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn’t have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:

All relevant code and content has been included in this CodeSandbox. Due to the use of karma/mocha, tests must be run locally. Inline comments add detail to behavior and expectations.

To see the tests pass, switch “test” to “production” in the karma.js file.

What is the expected behavior?

Typically, DevTools are used in a different context from running specs—automation vs investigation, for lack of more precise terms. It should be an option rather than the default when using React in a non-production environment. At least in an environment of test, where spec runners are conditionally sensitive to global errors, developers must have the option to disable or disallow this behavior as it is implemented at this time.

For a second, perhaps more intuitive option, refer to this portion of the mentioned comment, talking about “pause on caught exceptions”:

This is untintuitive, though, because even though React has caught the error, from the developer’s perspective, the error is uncaught.

When an exception during render is captured using componentDidCatch or try/catch as mentioned above, the exception should be considered “caught,” as the developer has explicitly created an error boundary around this render. In this case, expected behavior would be for the error to not be surfaced globally and for the developer to debug any exceptions within the error boundary they defined.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

This is present only in the non-production version of React 16+. The development or test environments of React 16+ feature this behavior. React 15.* and below do not have this issue. Prior to React 16, explicit try/catch handlers were solely responsible for being an error boundary during render.

[jacobrask]

I want to be able to throw things like network or authentication errors anywhere in my tree and catch them at a boundary to show an error message, instead of handling these errors at every place they can occur in my application. Like I would use try/catch.

If a network error occurs in a regular image somewhere I can just show alternative content or nothing, if it happens in a gallery it is a fatal error that I want to handle differently, but my image component can throw the same error. Error boundaries are great for this use case.

The console and Sentry will be spammed with errors because of this though, and adding a global error handler will silence legitimate errors that I have not caught with either try/catch or componentDidCatch.

It was surprising and unintuitive to me that componentDidCatch behaved differently than catch.

[gaearon]

Can you add an error handler, like

window.addEventListener('error', e => {
  e.preventDefault();
});

?