-
-
Notifications
You must be signed in to change notification settings - Fork 226
fix: de-duplicate Java.Lang.RuntimeException on Android #4509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| options.EnableScopeSync = true; | ||
| options.ScopeObserver = new AndroidScopeObserver(options); | ||
| // Don't capture Java Runtime exceptions in the managed SDK, since we already capture them in the native SDK | ||
| options.AddExceptionFilterForType<Java.Lang.RuntimeException>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: test
Is there a (somewhat) straightforward way to (unit) test the suppression of the double capture?
Perhaps via
#if ANDROID
SentrySdk.CauseCrash(CrashType.Java);
#endifor would this need to be an integration test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find any suitable place for testing this. Native SDKs are not initialized in unit tests, and integration tests only run on desktop platforms. Once we have the infrastructure for e2e tests, though, then we can hopefully start testing these things:
jamescrosswell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thank you!
Java runtime exceptions are caught in two layers:
For example, the result of exactly one
CrashType.JavaThreadand oneCrashType.JavaBackgroundThread:Fixes: #4237