-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Open
Labels
proposalThis issue is a proposal, usually non-trivial changeThis issue is a proposal, usually non-trivial change
Description
Have you read the Contributing Guidelines on issues?
- I have read the Contributing Guidelines on issues.
Motivation
Using the new reportError api permits to trigger window.onerror and let users (or error reporting services) to plug their own error handling behavior
https://www.stefanjudis.com/blog/reporterror-a-method-to-report-to-global-event-handlers/
This is not 100% supported though
https://caniuse.com/?search=reportError
React recently merged a PR using this feature
/* global reportError */
export const logRecoverableError =
typeof reportError === 'function'
? // In modern browsers, reportError will dispatch an error event,
// emulating an uncaught JavaScript error.
reportError
: (error: mixed) => {
// In older browsers and test environments, fallback to console.error.
// eslint-disable-next-line react-internal/no-production-logging, react-internal/warning-args
console.error(error);
};We should probably do the same and use reportError for any recoverable error that we usually console.error.
There are many places where we deal with recoverable errors, particularly around localstorage usage.
We could eventually expose a core error reporting API that triggers lifecycle a new client module lifecycle event, this could allow users to build error reporting plugins like Sentry?
Self-service
- I'd be willing to do some initial work on this proposal myself.
Metadata
Metadata
Assignees
Labels
proposalThis issue is a proposal, usually non-trivial changeThis issue is a proposal, usually non-trivial change