Hi,
We used Firebase Crashlytics and logged every rest response, which was !200 as non fatal. This way I was able to see, if the backend had any special issues.
Now we switched to Flutter and can’t use Firebase Crashlytics, because every issue will be non fatal even the real error. Sentry seems to be the better solution for that. I know how to implement it as uncaught exception handler so we can receive all errors in our code.
Currently, I want to implement the non fatal behavior, but I don’t know the right way. Should I set the SeverityLevel to info or is there a better solution for it?
Thanks in advance.
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 level.
A distinction is useful in order to prioritize which issues to tackle first. Sentry has the concept of handled vs 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 handled vs 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.