-
Notifications
You must be signed in to change notification settings - Fork 229
Add More Data For RemoteInvocationException #8240
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
| return false; | ||
| } | ||
|
|
||
| reporter.ReportFault(remoteInvocationException, remoteInvocationException.Message, remoteInvocationException.ErrorCode, remoteInvocationException.ErrorData, remoteInvocationException.DeserializedErrorData); |
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.
Does the actual exception give us no useful information at all? I would have thought we'd somehow want to combine all of the info together.
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.
It does, and we're still keeping that info. We're just adding more now
| continue; | ||
| } | ||
|
|
||
| faultUtility.AddErrorInformation(data.ToString()); |
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.
whats a faultUtility and what does it do?
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.
This is part of the Fault API we consume from VS
| { | ||
| if (handler.HandleException(this, exception, message, @params)) | ||
| { | ||
| handled = true; |
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.
My first thought was that we should stop iterating after it's been handled, but we could easily handle it twice (one to log and one to attempt recovery perhaps?), and so long as there aren't a ton of Exception handlers it shouldn't matter too much. No real suggestion, just putting some thoughts out there in case you can make better use of them than me.
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.
Yea I wasn't sure what the best behavior here would be. I think it's just a best guess until we add more
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 agree. It might be worth adding a comment so that we remember that we weren't quite sure about this behavior when it was written.
src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/JsonRPCFaultExceptionHandler.cs
Outdated
Show resolved
Hide resolved
maryamariyan
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, thanks
…CFaultExceptionHandler.cs Co-authored-by: Ryan Brandenburg <[email protected]>
…gard/razor into exceptions/remoteinvocation
* upstream/main: (29 commits) Consolidate roslyn versions (dotnet#8103) Don't set always-auth Fix darc publishing (dotnet#8275) Update LSP protocol DLL version reducing line comment length Avoid killing the process when a login window is closed. Clean up serialization benchmarks Accepting applicationUrl with more than one url. "applicationUrl": "http://localhost:7104;https://localhost:7105" Removing more code related to blazorwasmdebuggingextension Add More Data For RemoteInvocationException (dotnet#8240) Trying to completely remove the BlazorWasmDebuggingExtension and getting URL information from launchSettings.json Cleanup Fix TextMate missing item Use ImmutableHashSet rather than HashSet in LegacySyntaxNodeExtensions Use more efficient stack for FlattenSpansInReverse Use an object pool rather than a thread-static Remove unneeded 'aggressive inlining' attributes Add lock to protect against multi-threaded access Rename fields to use _lazy prefix Clean up and further optimizations in LegacySyntaxNodeExtensions ...
Add specific data from RemoteInvocationException to Watson cabs that get uploaded for reporting telemetry faults