Skip to content
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

Fix unhandled exception not captured when hub disabled #2103

Merged
merged 8 commits into from
Jan 4, 2023

Conversation

mattjohnsonpint
Copy link
Contributor

@mattjohnsonpint mattjohnsonpint commented Dec 31, 2022

I noticed that the Sentry.Samples.Console.Basic example wasn't working when run on my Mac with the net48 target, but was working fine with the net6.0 target, or on Windows with either target.

After some investigation, it turns out that the Mono desktop runtime will call any Dispose from a using statement (or any finally block) before it invokes AppDomain.UnhandledException or similar events. That's probably a bug in Mono, as the behavior on .NET or .NET Framework is to fire those events immediately and not dispose. This doesn't look like it will be fixed in Mono any time soon, so we should accept the current behavior.

The problem is that if Hub.Dispose is called before the unhandled exception integration captures the exception, the hub will have been disabled and the exception won't be captured. The solution thus is to allow the unhandled exception integration (and similar) to capture even if the hub has been disabled.

While resolving this, I also noticed that we were checking IsEnabled only on extension methods like CaptureException, CaptureMessage, etc. So it was always possible to still send events post-dispose by calling CaptureEvent directly. That is a separate bug, but also resolved in this PR. The hub now checks if it is disabled before capturing anything, rather than the extension methods. An internal CaptureEventInternal and some related code will allow the integrations to bypass those checks and still capture on disabled hubs.

This change means that no events will not be captured post-dispose unless they come from an internal integration. That was always the intention, but only behaved that way with extension methods like CaptureException, and not with the basic CaptureEvent method.

Copy link
Contributor

@bitsandfoxes bitsandfoxes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean that if the SDK got initialized it'll always capture Unhandled Exceptions even if it has been closed on purpose?

src/Sentry/Internal/IHubEx.cs Show resolved Hide resolved
src/Sentry/HubExtensions.cs Show resolved Hide resolved
@mattjohnsonpint
Copy link
Contributor Author

Does that mean that if the SDK got initialized it'll always capture Unhandled Exceptions even if it has been closed on purpose?

Yes. An unhandled exception leads to a crash, so we want to always catch those.

Copy link
Contributor

@bitsandfoxes bitsandfoxes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@mattjohnsonpint
Copy link
Contributor Author

This had the side effect of fixing #321 for exceptions. #2319 fixes it for transactions as well. 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants