Unhandled error is displayed twice

[gaearon]

This was a bit weird:

Look at the last log.

Notice how our internal error that we're supposed to just give to the error boundary is said to be uncaught. I wonder why. It doesn't look like intentional.

[gaearon]

Hmm. I didn’t see this before because I was testing the “swallowing Promise” case specifically.

[gaearon]

The annoying thing is that even if you set up CORS, you still see the same error twice. Unless you’re swallowing it.

Once because it is thrown in the inner event, and the other time because it is rethrown in the scheduler. And we can’t avoid rethrowing because that would change the flow between DEV and PROD.

I wish there was just some way to silence the second one.

[gaearon]

For context, the reason it happens is because we intentionally let the browser interpret an error as uncaught before we rethrow. The justification is discussed in #10474.

If you follow the advice in the error and add an error boundary (which you should!), you will only see the error once. So that's not a huge problem in day-to-day workflow. In fact it nudges people to add error boundaries which is nice.

Another justification for this is that if you accidentally swallow an error we still print it once. That alone makes this worth it IMO. We’ve had hundreds of comments and dozens of issues caused by people swallowing their own errors, and the fact that we will print them at least once now seems like enough benefit to compensate for printing them twice when they’re uncaught, un-swallowed, and don’t have a boundary.

[mjomble]

Is there currently a way to prevent dispatching the error event twice in a case as simple as this?

window.addEventListener('error', () => console.log('error event dispatched'))
const onClick = () => { throw new Error('foo') }
ReactDOM.render(React.createElement('button', { onClick }, 'test'), container)

Because the error is thrown in a click handler rather than render(), error boundaries don't seem to help.

PS. Not sure if this belongs here or a on different issue or if I should open a new one.

[gaearon]

Does an approach like #10474 (comment) help?

[mjomble]

Probably. Something like this works as well:

window.addEventListener('error', (evt) => {
  if (evt.error.markedForReactWeirdness) {
    evt.preventDefault()
    return
  }

  evt.error.markedForReactWeirdness = true
  // ...regular error handling here...
})

But I considered that a temporary hack, hoping that a more elegant solution is (or will be) available :)

[gaearon]

Why is this important for you? The duplication only happens in development mode. And presumably error logging etc should only happen in production.

[mjomble]

Ah, good point, I forgot that this wouldn't be an issue in production mode.

In that case it's just more of a minor annoyance.
My app displays errors caught in the global handler, so while developing the error display feature, they always show up twice, unless I hack the duplicates away.

[gaearon]

Tagging as wontfix.
The behavior is intentional as explained in #10384 (comment).

[gaearon]

If someone comes here looking for a solution for jsdom, a few related links:

jestjs/jest#5223 (comment)
#11098 (comment)

[jgentes]

@gaearon could you clarify what you mean by The duplication only happens in development mode. I'm running my app in production mode, with webpack, etc, and I see duplicate errors in my console (and sent to Bugsnag).

My app config specifies the boundary above Provider:

ReactDOM.render(
      <ErrorBoundary>
        <Provider store={store}>
          <Routes history={browserHistory}/>
        </Provider>
      </ErrorBoundary>,
      document.getElementById('app')
    );

[gaearon]

@jgentes "The above error..." stuff is only logged in development.

If you're seeing some other symptoms please file a new issue with an example.