-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow user to choose if an error has been handled by an ErrorBoundary #14554
Comments
Hey @HHK1 thanks for writing in! This sounds reasonable to me. Are you interested in opening a PR to contribute this? If not, no worries, I can take a look. Just asking :) |
Interested in opening a PR. From the looks of the previous implementation, it doesn't look like much. |
awesome, thanks! |
Initial implementation is here: #14560 |
Thanks, I'll take a look! |
Problem Statement
#8914 was setting errors caught by ErrorBoundaries as unhandled.
Then, #10985 was opened, asking to use the
fallback
property in order to decide if the error should be considered handled or not, and implemented in #10989.I'm in a situation where I do not want to mark my errors as handled, despite using an ErrorBoundary. The reason is that it's a global error boundary, and at that point I consider that it's equivalent to a crash. I want to include that in my Sentry issues when filtering with unhandled, and I want to have it count towards the crashed sessions.
Solution Brainstorm
Modify the existing ErrorBoundary to pass an explicit
handled
property, defaulting toundefined
.For retro-compatibility the presence of the
fallback
property should be used ifhandled
is not set, otherwise the setting should be used directly to mark the error as handled or not.The text was updated successfully, but these errors were encountered: