-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Catch exceptions within LazyToolTip #52947
Conversation
Fixes AB#621364
Although there's no reason to be crashing processes for this, I'm worried that it appears the internal bug isn't really root caused -- is the plan to continue to investigate that in a later release? |
@jasonmalinowski it is unlikely that this will be investigated or fixed. The hit rate is not significant relative to other non-fatal errors and I haven't seen any reports of specific negative side effects (i.e. the standard prioritization process for non-fatal errors does not indicate time should be spent performing the investigation which would be a prerequisite for a fix). |
@sharwell I guess if the exception being thrown is due to projection being out of whack, this would potentially be just one of many potential crash points. |
@jasonmalinowski It's possible a crash still occurs, but most common paths go through top-level exception handlers that either report telemetry or show a gold bar (or both). This path was different because we were called directly by WPF. |
I dont' mind this in that all it is doing is taking something bad, and making it less bad for the user. We're still in a broken state, but we'll still get a watson from this. Hopefully though the user can continue. If they can't, that's ok as that's no worse than the state we're in now. |
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'm signing off. However, we should only take this through if Jason is ok and doesn't want something else done here as well. From my perspective though, this is strictly ok as not makign things worse, while potentially in some cases making it better for users.
For us, we can still track thsi trhough watson as we try to determine the root issue and what would need to be done with it.
@sharwell @CyrusNajmabadi Agreed; there's no reason to crash here, but the internal bug is now resolved, and no investigation to the root cause will now happen. I get the investigation is hard, but that'll still need to happen. |
@jasonmalinowski The Watson issue is closed, but we automatically open issues for NFEs if they are hit a significant number of times in telemetry. According to @ryzngard this analysis process runs weekly. |
This change converts a case involving a rare application crash to use our standard error handling/reporting strategy without crashing.
Fixes AB#621364