Skip to content

JVM/Android issue title not derived from the most deeply nested error  #64074

@grandstaish

Description

@grandstaish

Environment

self-hosted (https://develop.sentry.dev/self-hosted/)

Steps to Reproduce

Try/Catch on the JVM allows you to catch an exception and throw a different one, listing the originally thrown exception as a cause:

try {
  potentiallyDangerousCode()
} catch (e: IOException) {
  throw AppException(e)
}

In this example, if potentiallyDangerousCode throws an IOException, then Sentry will make the title of the issue AppException. This is not useful because because in this imaginary example any number of IOExceptions could have occurred in potentiallyDangerousCode! It should be easy to use the issue title as a way to distinguish these issues. Therefore Sentry should do what Firebase does and use the most deeply nested cause for deriving the title.

This is particularly problematic on Android, because potentiallyDangerousCode becomes your entire app! Source. So in Android apps, unless your exception thrown is a RuntimeException, then Sentry will always title the issue as RuntimeException — com.android.internal.os.RuntimeInit$MethodAndArgsCaller in run at line 562.

I listed this as a bug, but it could also be a feature request? Feel free to change it if it's intended.

Expected Result

Title of the issue should be derived from the most deeply nested exception cause, not from the topmost one.

Actual Result

Title of the issue is derived from the topmost exception.

Product Area

Issues

Link

No response

DSN

No response

Version

No response

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions