Sentry doesn’t make the same distinction as Crashlytics. At least not in the same way.
By default, all our SDKs sends all errors, and Sentry shows them all in real-time.
And there’s an API to capture errors, as you already use. With that you can send anything else you want. Errors or messages, which can include a
A distinction is useful in order to prioritize which issues to tackle first. Sentry has the concept of
unhandled error. An unhandled error in a mobile or desktop app usually means the app crashed. That’s not true for a web server which would simply return 500 to the caller. For that reason the term
crash is avoided. Similarly the level
fatal could be a logging library integration that sent a
level=fatal event but kept the process running.
For those reasons, such terms are avoided as they need more context to understand what they really mean and
unhandled are clear enough.
How that technically works is that an error was either
handled or not based on a field in the event called
exception mechanism. This is going to be added to the Flutter SDK soon. But as you suggested, you can use the
SeverityLevel and filter in Sentry for events with level
fatal. It will bring up the right events the same way.