Allow to handle caught error and eliminate the error logging

[Fonger]

Goals

1. Error handled in Error boundary are unconditionally print to the console, and it make a lot of noise in our server logging.
   We should allow to avoid this if the error is handled in error boundary or error.js

2. We also see a lot of Error: NEXT_HTTP_ERROR_FALLBACK;404 in our sentry logging

Non-Goals

No response

Background

Prior to react 18, this is unavoidable. Now react 19 introduce "onCaughtError" on createRoot function, it's now possible.
facebook/react#15069 (comment)

Proposal

Allow to custom react 19's onCaughtError and let developers to decide the behavior.

[egemon]

I wonder how this should be communicated to NextJS team?

[yajatkaul]

This makes a lot of sense. Right now, the unconditional logging is pretty noisy — especially since errors that are already handled by an error boundary don’t really need to end up cluttering server logs or external monitoring tools. From a developer’s perspective, “handled” should mean exactly that: we chose to catch it and recover, so we shouldn’t also be forced into double-reporting it.

React 19’s onCaughtError is a really nice opportunity to improve this. If Next.js exposed a way to customize or override that handler, it would give developers the flexibility to decide when and where to surface those errors (e.g. only log unhandled ones, or only send certain categories to Sentry). That way, apps that care about clean observability could reduce noise, while others could still opt in to the current behavior.

I like the idea of this being opt-in, so nothing breaks for existing apps, but power users can wire in their own logging/monitoring strategy.