-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Description
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
Labels
Projects
Status