Error name as class name instead of exception name

SDKs
1

Hi, our company’s Android app just recently integrated with Sentry. We’re trying to migrate away from using Firebase Crashlytics. As we have integrated, we noticed that most of the errors reported to Sentry show the exception names as the titles. We wrap our exceptions in a custom HandledException for non-fatal errors. On Firebase Crashlytics, this information is wrapped inside the error detail while Sentry puts this exception class name as the title of the error.
This has proven to be very difficult to navigate for all of the engineers who are used to Firebase bug naming.

Is there any configuration I can do to update the error title to using the class name (where the exception is thrown)? Instead of the exception class itself?

2

hey @committedteadrinker.

not sure if I’ve got this right, mind sharing a pseudo-code of your custom HandledException, a fake RuntimeException("test"), how you wrap it and how you send it to Sentry and what you expect as a title, it’d be easier for understanding the problem.

My guess is:

class HandledException(e: Exception) : Exception {}

so you do:

val exc = HandledException(RuntimeException("test"))
Sentry.captureException(exc)

what would you expect as a title? the issues page and issue details have a title (bold) and a subtitle (normal), which one are you talking about?

The title and subtitle of the sample above would be:

Title (bold): HandledException
Subtitle (mormal): java.lang.RuntimeException: test

Also, which version of the Android SDK are you working on? thanks.

3

Thanks for the reply.

Our HandledException is

class HandledException : Exception {
    constructor(message: String, vararg args: Any?) : super(String.format(message, *args))

    constructor(exception: Throwable) : super(exception)
}

The expectation for the title of the issue would be the class where this exception is thrown from like what Firebase is providing us with:

Firebase list of issues
Firebase list of issues1426×450 34.3 KB

Also, the Android SDK version is: 2.2.0

4

For extra detail,

Currently, Sentry does this instead:
Sentry list of exceptions

5

thanks for your reply @committedteadrinker

Actually, this was like that and it has been changed to keep compatibility with the older version of the Android SDK aka v1

See: https://github.com/getsentry/sentry-android/issues/363

Both ways would have a valid use case, it really depends on the nature of the Exception and how you’ve raised them.

A workaround would be to reverse the order of the exception list, because the title, subtitle and culprit are inferred from that list, based on the sorting.

See: https://develop.sentry.dev/sdk/event-payloads/exception/

Try to set a BeforeSend and reverse it, and check if this actually solves your problem.

SentryAndroid.init(
        this,
        options -> {
            options.setBeforeSend((event, hint) -> {
                if (event.getExceptions() != null) {
                    Collections.reverse(event.getExceptions());
                }
                return event;
            });
        });

If you believe that we should change this in the SDK instead, please open an issue on https://github.com/getsentry/sentry-android/issues and we can discuss this further along with more interested people.

1 Like
6

Thanks for the prompt reply @marandaneto

I will try this in our next release. For now, the workaround should be OK.

I will open an issue on the SDK if this impacts heavily on our performance (it shouldn’t).

1 Like