-
-
Notifications
You must be signed in to change notification settings - Fork 223
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
Exceptions not handled by user code should be unhandled: true
#456
Comments
unhandled: true
This problem is relevant to Unity too where unhandled errors (in C# scripts) also don't crash the process. But could render a blank screen |
I don't see how this would be possible without changing our protocol, we also cannot forget that Flutter Apps can also crash in the native layer or if Flutter itself has a bug so we need 2 things. handled by the user vs not handled by the user. both things are already filterable via the mechanism btw. |
Similar to Unity. A
Let's discuss this again on the API evolution Thursday. |
I'll write down a DACI that introduces a new flag that would be added to the protocol, which would mean an unhandled error happened but it didn't crash the app, JS and RN have the same issue, this should consider the other platforms too. |
Are there any updates on this? |
unfortunately not, I'll try to get back at it next quarter, since it's a change on a few SDKs, frontend, and also ingestion, requires planning and prioritization, cc @bruno-garcia |
In the meantime, would it be possible to add a tag like |
If you want to query/filter non-handled events on Dart/Flutter using Sentry Discover, you can search for e.g. |
Crashlytics also records unhandled exceptions in Flutter as fatal which is kinda the same as the unhandeld in Sentry. |
The only problem for us doing it is that it breaks the release health feature yet, otherwise, all sessions will be considered "Crashed" instead of "Errored" only. |
For this matter, I managed to mark some exceptions as unhandled manually by adding an For context: In our case we wanted to make sure those errors were considered on the Release Health metrics |
#1116 is a larger initiative but I don't expect something right away, I suggest changing this on the next major (v7). |
Correct. |
We need to be sure that once there's an unhandled exception on the Hybrid side, and the session is marked as crashed on the Native side (last state of the session), since the app won't crash, the Native side has to start a new and fresh session. |
Example where this should be changed,
Places that have handled: true should be handled: false in case they are unhandled handlers.
|
@marandaneto The 'handled' flag on the mechanism is an optional. Am i assuming correctly that |
I'd say |
Ok, so we not only need to look at Mechanisms that explicitly set |
Nope, let's be a bit more pragmatic here, where it is |
just to be clear, the omission of a mechanism means, the error was handled, likely manually captured, that's why |
Currently all exceptions are marked as
handled
.This decision was made because exceptions in Flutter don't crash the app and thus sessions should not be marked as crashed.
Though we want to mark exceptions as unhandled to indicate that an exception caught by the root zone handler was not handled by the user.
There should be a way to differentiate.
This issue is a result of a discussion on Discord.
The text was updated successfully, but these errors were encountered: