-
Notifications
You must be signed in to change notification settings - Fork 822
Diagnostics logger: remove exception rethrow during recovery #15907
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
Watsonable. Really? :D Have you found the reason why this was put there initially? |
I goes beyond the initial Git commit in this repo, so can't say for sure. Our guess was the authors wanted the process to crash to analyse the crash. We never want an IDE crash because of an error during analysis. 🙂 |
That's exactly the reason. The idea is - we want to crash if we can't recover/repair it. In VS it won't crash the whole IDE, but only extension. |
The problem is it's called in |
I think we observed the whole VS process crashing because of an uncaught exception (see #15906 for the fix of that). |
What I meant by that, if we hit something truly irrecoverable. Like, we can't read pickled data, or some critical issue, we want to crash. I'm not sure why is it in the diagnostic logged. |
I think that even in this situation we should always try to continue the work and report the error via diagnostic. Currently this PR hides the error, but I'm going to improve it before the merge. |
The current behavior (just let the exception to be rethrown several times in hope somebody/or even an attached debugger will catch it later) looks unusual/dubious to me. And it provably doesn't always work. Doesn't VS have any better error reporting facilities, which would allow reporting an exception? Since we know that exceptions of this kind are normally pretty rare (well, VS doesn't crash for you every day, is it?) due to very good quality of the compiler code (I am not ironic, I really think so), perhaps we could just follow the existing error reporting guidelines and show exception info somewhere in the status bar or whatnot? Or maybe there's some internal error processing pipeline wired with IDE telemetry that will automatically report the collected errors when allowed by the user? |
Controlled report is preferable, but it doesn't allow to collect nearly as much info as watson allows. Also, we can't really collect much from the compiler itself.
Rather limited, I whink the only way to collect full watson dump was to crash sadly.
Yeah, that would be nice, but will require significant rewrite and a bunch of GDPR-related approvals to make sure we don't collect something we shouldn't. |
What should we do here? Prior to this PR, this code would just break error recovery in the type checker in many cases, also breaking analysis of subsequent files. It all happened in cases where we expected errors to be recoverable, because the only place where this rethrow is happening is during error recovery. What short-term options I see:
|
I've rechecked this fix without #15909 applied, and it turns out the errors aren't hidden and are properly reported via a diagnostic: ![]() Please note, that the rest of the analysis has also managed to finish, as can be seen from the highlighted identifiers. With this info, I'd vote for a better exception logging (so the stacktraces are available somewhere) and not rethrowing the exception, at least by default. @vzarytovskii Please let me know how I should proceed here. |
Yeah, not rethrowing is the right thing to do. |
0d23553
to
017841c
Compare
I've added I've checked it on |
Partially fixes #15905. Removes rethrowing exceptions in
DiagnosticsLoggerExtensions.ErrorRecovery
, which was making the error recovery non-existent for many exceptions other thanInternalError
. System exceptions likeArgumentException
orNullReferenceException
were never recovered because of this call, breaking analysis for the whole file in many cases.With this change the analysis recovery properly continues but the internal error isn't reported anymore, I'm still looking into it.