-
-
Notifications
You must be signed in to change notification settings - Fork 651
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
errors: Don't panic in wasm_vm
#1827
Conversation
which is returned by calls to `lock` on various types of locks from `std`. In our case, some of the locks we try to acquire in `wasm_vm` can contain an `mpsc::Sender`, which is `!Send` and hence doesn't work with `anyhow`. Turn the `PoisonError` into an error string instead and returns that as `anyhow::Err`.
in the WASM VM codes server API. Note that this doesn't include the Plugin APIs. Mark the error as `fatal` in `server/lib`, where the wasm thread is created. This will cause zellij to report a proper error (and log it) when any of the plugin-related functions fails. Unfortunately, this closes the channel to the WASM thread. Hence, when loading the plugins upon startup fails, the error reported in the terminal (visible to the user) hints towards a call in `plugin_pane` being the culprit. However, the real error will be contained in the logs. Also add an error message and print it to the user in case that the plugin failure was caused by a plugin version mismatch.
This is very cool!!! About the wording: I'd add something about clearing the plugin cache as a possible solution (in the Also: is there any chance we can show this in STDOUT as well as the logs? A lot of users wouldn't know to look there. |
Not quite yet. As you see on stdout, zellij dies trying to receive a message from the Ideally I'll manage to send a message to the Edit: Here's what it looks like:
|
when failing to receive a message from the plugins for rendering pane contents.
which removes calls to `unwrap` from `wasm_vm` and prints sensible error messages when errors in the plugins occur.
Removes calls to
unwrap
andpanic
in the server API ofwasm_vm
, replacing explicit calls topanic!
with.fatal()
instead. Leaves the plugin API unchanged.The most notable change is that now, when we load incompatible plugins (older versions, whatever) we get pretty error messages. In the terminal it looks like this:
which is just an effect caused by the initial error (and the next thing on my TODO). The real error is now sitting in the logs:
The runtime error about having reached unreachable code is still as useless as before, but that's out of our hands.
@imsnif Are you fine with the wording I chose? In particular this bit: