Can an error boundary prevent React's error logging?

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?

[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]

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