Fix `handled` data and differentiate between unhandled errors and crashes

[ueman]

Description

From getsentry/rfcs#10 (comment), emphasis mine:

The JS SDK team chatted and agreed that as a first step, we will start sending improved (even if not perfect) data somewhere else (TBD where) in the event, so that a) the scale of the problem can be quantified, and b) any backend or UI folks who do eventually pick up that end of the work have example data to work with. (This will likely be somewhere viewable in the JSON but not directly in the UI for the moment, since for now it's really just analytics.)

I'll update here once exactly where and exactly what we'll send is hammered out. Once we do that, maybe other SDKs can do a similar thing.

I really would like to see that in the Dart/Flutter SDKs too.

Relates to

• Fix handled data and differentiate between unhandled errors and crashes sentry-javascript#6073
• Exceptions not handled by user code should be unhandled: true #456
• Introduce additional types of exceptions next to mechanism.handled exceptions rfcs#10

[marandaneto]

@ueman this is a dupe of #456 IMO
Only one SDK needs to have good enough data to understand the problem a bit better, of course the numbers can vary but its still the same thing.
On Flutter side, we can already get this data because we have access to the mechanism type, we know that runZonedGuarded, isolateError, FlutterError and PlatformDispatcher.onError are unhandled, so its already possible.

[marandaneto]

@lobsterkatie let me know if you all work on getsentry/sentry-javascript#6073
Maybe we can align this either way.

[lobsterkatie]

@ueman this is a dupe of #456 IMO

Is it? That's just about fixing the handled value to reflect reality, whereas this is requesting the dart SDK do what the JS SDK is proposing to do and send one of three states.

@lobsterkatie let me know if you all work on getsentry/sentry-javascript#6073 Maybe we can align this either way.

Sounds good. It's in the backlog, but I'm going to push for it to happen since it'd be nice to get the ball rolling on actually finally fixing this stuff!

[marandaneto]

@lobsterkatie

s it? That's just about fixing the handled value to reflect reality, whereas this is requesting the dart SDK do what the JS SDK is proposing to do and send one of three states.

That's what I meant by looking at Dart/Flutter mechanisms, we already know if it's unhandled and it's not properly set as unhandled (we can query that on Looker -> (total events vs unhandled events not marked as unhandled).
So there's no data to gather here, it's either fix it or not.

[lobsterkatie]

Ah, I see what you're saying. Thanks.

@smeubank - I know there aren't as many dart users as JS users, but good to know that we can already gather some data on this score!