React: Can an error boundary prevent React's error logging?

[silverwind]

I noticed this unconditional console.error which I'd like to prevent to keep the console clean from errors that are already "caught" in an error boundary.

Maybe a condition on capturedError.errorBoundaryFound could prevent this logging?

[gaearon]

For now we'd rather not allow it because it makes it too easy to swallow errors (such as if the error boundary itself is buggy).

[silverwind]

Right, I see reasoning in that, preventing error logging should require more than just the existance of a boundary.

Browsers allow to suppress logging uncaught errors to the console via event.preventDefault() in a error event handler on window. Maybe a something similar could be done from a error boundary too, like error.preventDefault().

[anilanar]

Error swallowing should be opt-in. I'd like to swallow certain errors and not others:

componentDidCatch(error) {
  // I'd like to swallow the error
  if (error instanceof MyExpectedError) {
    // somehow suppress the error?
  }
}

[jamstooks]

I'd support this feature as it would be nice to de-clutter our test output.

[EyalPerry]

@gaearon

consider the following production issue we are facing:
We are using a third party logging service, that logs all console.error calls automagically- which is debatably awesome and at the same time a given fact.

Naturally, we have our own ErrorBoundary implementation:
We want to slap on extra information special to the boundary instance-
So our error boundary component receives this information as props / context,
And logs the error along this information using the third party's sdk when an error occurs.

As a result of this implementation, when a component fails, we have two separate errors logged in our monitoring pipeline:
One which react logs, with barely any info, which comes from console.error
And one with everything we need to know, which we explicitly logged via the third party library.

Since this redundancy is confusing and not acceptable
We are now facing quite a dilemma:

If we don't explicitly log, we lose error specific info.
We also rely on react to do the logging for us, which is a bad idea in the long run.

if we explicitly log - we get two separate events in our monitoring pipeline, which is confusing and noisy, since our monitoring pipeline is automated and triggers a whole lot of internal processes.

I bet that we both believe console.error to be a side effect.
As an app developer, wouldn't you agree with me that such a side effect should not be invoked by a UI library without the possibility to opt out?

It's great that I can isolate failures to granular regions in the application- anything other than that, should not be decided for me as a developer.
I wouldn't want to see anything in the console which I did not put there.
Especially if it renders the entire stack of my component tree structure, uglified or not.

On the other hand, I do understand where you're coming from by saying you don't want it to be easy to swallow errors, so how about this as middle ground:
You could move the invocation of console.error to componentDidCatch,
Which would be the default implementation unless overriden.

if you think of it, this is the correct thing to do, since componentDidCatch is meant for exactly this.
To quote the docs:

componentDidCatch() is called during the “commit” phase, so side-effects are permitted. It should be used for things like logging errors

you say console.error and I say thirdPartyLibrary.logError.

The means of logging should be up to app developers, especially if they went through the trouble of setting up Error Boundaries.

Since Error Boundaries are basically logging components with some conditional rendering, and since I bet our logging provider is not the only one which logs console.error calls, wouldn't you say this issue should be solved in a more extensible manner?

As for buggy error boundaries, IMHO, you should not care about them.
It's just another failed component, so let it fail until it either crashes the entire tree or another boundary catches it. Since react is solely a UI rendering library, why should it decide what happens when rendering fails?

[anilanar]

@EyalPerry hit the nail on the head. Is there anything more to say? Shall we patch console.error?

[tonix-tuft]

@anilanar I completely agree with you, I think we should really have the possibility to suppress the logging of some errors which have been handled in error boundaries.

I think that we should have the power and responsibility to decide what to log and what not to log, especially in production.

In my case, if my app has been deployed in production and an error boundary catches an error, I wouldn't want to log the error to the console leading to information disclosure for some "more smart" users who open the browser's console to see what went wrong, or at least, I would want to be able to decide whether to log a certain error captured by an error boundary or not.

Also, I think that, when using create-react-app, it would be great to have the ability to suppress the error overlay for some errors caught by the error boundary (not all, but some), but that's another story...

[ElForastero]

It would be nice to have a control on logging errors to console.

For example, I like to use Error Boundaries for handling 404 exceptions in my apps. This way I don't need to call a redirect to some route or put the rendering logic inside my components.

Regularly I just throw a NotFoundException and seeing an error in console is not something I expect.

I would agree with @EyalPerry that moving the logging into default componentDidCatch would be a nice solution.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[anilanar]

Don’t close. We can’t seriously unconditionally log this anymore.

[art-in]

I have the opposite problem. Error is __not__ logged to console in dev build.

The above error occurred in the..., but nothing is above.

So if I console.error it in componentDidCatch it works in dev, but now I have two duplicate errors logged in prod.

v16.13.1

[zordone]

I'd like this to be fixed as well. The solution @EyalPerry suggested would be perfect.

[mariuscosta]

I vote for this too. I am also using an error handling mechanism like the one described by @ElForastero.

[kumar303]

Does anyone have a workaround for this while testing? I want to real-render a component under test, catch the error, and make an assertion without seeing error logging, especially as one can't hide logging in jest.

[MatiasManevi]

Does anyone have a workaround for this while testing? I want to real-render a component under test, catch the error, and make an assertion without seeing error logging, especially as one can't hide logging in jest.

This is my hacky workaround:

const swallowErrors = yourTestFn => {
     const error = console.error
     console.error = () => {}
     yourTestFn()
     console.error = error
}

// Then your test
it('tests something without console log' , () => {
      swallowErrors(()=>{
            const wrap = mount(<ErBoundary><Child/></ErBoundary>)
            // ... expect errors ...
      })
})

Or, you can do as this guy here