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

[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

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-issues for triage ⏲️

[scttcper]

Thanks for reporting, seems like something we should support better. I've added it to our backlog

[armenzg]

Has this been fixed after getsentry/sentry-java#3212 got merged?

[mikejihbe]

Closing due to inactivity. Let us know if the patch @armenzg linked is insufficient.