Exceptions not handled by user code should be `unhandled: true`

[ueman]

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.

[bruno-garcia]

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

[marandaneto]

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.
app didn't crash vs app crashed.

both things are already filterable via the mechanism btw.

[bruno-garcia]

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.

Similar to Unity. A handled: false if it came from a Mechanism other than the Unity error handler would mean a crash.

handled by the user vs not handled by the user.
app didn't crash vs app crashed.
both things are already filterable via the mechanism btw.

Let's discuss this again on the API evolution Thursday.

[marandaneto]

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.

[ueman]

Are there any updates on this?

[marandaneto]

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