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 to undefined.
For retro-compatibility the presence of the fallback property should be used if handled is not set, otherwise the setting should be used directly to mark the error as handled or not.
Problem Statement
#8914 was setting errors caught by ErrorBoundaries as unhandled.
Then, #10985 was opened, asking to use the
fallbackproperty 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
handledproperty, defaulting toundefined.For retro-compatibility the presence of the
fallbackproperty should be used ifhandledis not set, otherwise the setting should be used directly to mark the error as handled or not.