sentry-java: Exception cause hierarchy seems to be reversed on Android

  1. https://sentry.io/recharge/consumer-android/issues/293914847/ (using com.joshdholtz.sentry:sentry-android:1.6.0)
  2. https://sentry.io/recharge/consumer-android/issues/293913146/ (using io.sentry:sentry-android:1.0.0)

Note that the message in #2 is a red herring, it’s the wrapping exception’s message which is almost never the useful one. #1 is correctly showing the root cause exception type/message.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 46 (1 by maintainers)

Commits related to this issue

Most upvoted comments

Here’s what I mean.
New: screen shot 2017-06-16 at 12 23 08 pm Old: screen shot 2017-06-16 at 12 23 13 pm

Having the exception message there at the top level makes it way easier to triage effectively. Especially on the list view: New: screen shot 2017-06-16 at 12 24 43 pm Old: screen shot 2017-06-16 at 12 24 34 pm

it actually walks down the exception chain and finds the topmost Exception that includes the app’s package name

Oh interesting, I think I missed that. Thanks much for the examples.

OK, with the random stuff I had to get to and 1.3.0 out the door I will give this one some real time next week.

Oh yeah, sorry, I had to go re-read some of this thread myself. I forgot about the whole culprit/transaction business…com.joshdholtz.sentry doesn’t just use traces[-1], it actually walks down the exception chain and finds the topmost Exception that includes the app’s package name. Which is great, because if I choose to wrap exceptions, it’ll give me the wrapper exception, but if it’s Android wrapping everything in a RuntimeException, I’ll get the one below that.

I just wrote ^ and realized it’s really dense, so a couple examples, given that my app’s package name is com.example.foo, and I have these custom exception classes: com.example.foo.TheActualCauseException, com.example.foo.MyWrapperException.

  1. The Android-wrapped-me case: RuntimeException -> com.example.foo.TheActualCauseException. This should log TheActualCauseException to Sentry.
  2. The I-wrapped-it-myself case: RuntimeException -> com.example.foo.MyWrapperException ->com.example.foo.TheActualCauseException. This should log MyWrapperException to Sentry (presumably because I’ve included additional information that wasn’t part of TheActualCauseException).

@bretthoerner I will ask here, but I don’t have the admin rights here yet so actually I believe I can’t. But I can share some screenshots:

Here are 3 issues, one was ClassCastException, another was IllegalStateException and the third was yet another unrelated issue on the same Activity class. But from the outside, there’s no way to know what really is the issue. screen shot 2017-07-14 at 14 21 59

ClassCastException issue in details, now we can see what really is it: screen shot 2017-07-14 at 14 22 30

Its not that it don’t looks right, it is in fact a RuntimeException, but the ‘culprit priority’ looks messy and makes user experience bad in the end.

Thanks for reporting, it’s good to hear from another Android user (as I’m not an actual Android dev, I just pretend to be one on TV).

Just to be clear, would the inner-most exception be the error you’d like to see (as reported above)? Or is it more complex than that?

Ah, that makes sense. Can you review this? https://github.com/getsentry/sentry-java/pull/413