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.

Start with the linked CodeSandbox and the referenced packages/shared/invokeGuardedCallbackImpl.js code, then run the local Karma/Mocha tests described in the report. Compare the development or test behavior with the production configuration in karma.js. Done means the explicitly handled render errors no longer pollute the test suite while the expected development behavior remains defined.