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

Handle non-async exceptions from LSP handlers #25

Merged
merged 2 commits into from May 20, 2022

Conversation

artempyanykh
Copy link
Contributor

@artempyanykh artempyanykh commented May 20, 2022

Continuation of the discussion in #24

The ordering is back to normal and exceptions are returned to the client as errors and shown to the user.

@razzmatazz
Copy link
Contributor

Lgtm!

@baronfel
Copy link
Contributor

LGTM, thanks for doing this. Do you want a release while we figure out what to do about the ordering question?

@baronfel baronfel merged commit a014ba8 into ionide:main May 20, 2022
@artempyanykh
Copy link
Contributor Author

No problem!

Do you want a release while we figure out what to do about the ordering question?

@baronfel I'm still vendoring the lib, so having an actual release is not super critical.

@artempyanykh artempyanykh deleted the fork-3 branch May 20, 2022 19:52
artempyanykh added a commit to artempyanykh/LanguageServerProtocol that referenced this pull request Jul 31, 2022
This is once again a continuation of ionide#25.

There were several issues with the previous version.
Catching exceptions in server's code and turning them into LocalRpcExceptions probably isn't the best because:
1. Notifications don't require a response, hence no error will be shown
   to the user. Effectively, this means any exceptions including fatal
   can get swallowed.
2. The context of the original exception is lost in conversion.
baronfel pushed a commit that referenced this pull request Jul 31, 2022
This is once again a continuation of #25.

There were several issues with the previous version.
Catching exceptions in server's code and turning them into LocalRpcExceptions probably isn't the best because:
1. Notifications don't require a response, hence no error will be shown
   to the user. Effectively, this means any exceptions including fatal
   can get swallowed.
2. The context of the original exception is lost in conversion.
@ghost ghost mentioned this pull request Oct 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants