mirror of
https://github.com/zellij-org/zellij.git
synced 2024-11-22 22:26:54 +03:00
6715f4629c
* utils/errors: Add `ToAnyhow` trait for converting `Result` types that don't satisfy `anyhow`s trait constraints (`Display + Send + Sync + 'static`) conveniently. An example of such a Result is the `SendError` returned from `send_to_plugins`, which sends `PluginInstruction`s as message type. One of the enum variants can contain a `mpsc::Sender`, which is `!Sync` and hence makes the whole `SendError` be `!Sync` in this case. Add an implementation for this case that takes the message and converts it into an error containing the message formatted as string, with the additional `ErrorContext` as anyhow context. * server/tab: Remove calls to `unwrap()` and apply error reporting via `anyhow` instead. Make all relevant functions return `Result`s where previously a panic could occur and attach error context. * server/screen: Modify `update_tab!` to accept an optional 4th parameter, a literal "?". If present, this will append a `?` to the given closure verbatim to handle/propagate errors from within the generated macro code. * server/screen: Handle new `Result`s from `Tab` and apply appropriate error context and propagate errors further up. * server/tab/unit: `unwrap` on new `Result`s * server/unit: Unwrap `Results` in screen tests * server/tab: Better message for ad-hoc errors created with `anyhow!`. Since these errors don't have an underlying cause, we describe the cause in the macro instead and then attach the error context as usual before `?`ing the error back up. * utils/cargo: Activate `anyhow`s "backtrace" feature to capture error backtraces at the error origins (i.e. where we first receive an error and convert it to a `anyhow::Error`). Since we propagate error back up the call stack now, the place where we `unwrap` on errors doesn't match the place where the error originated. Hence, the callstack, too, is quite misleading since it contains barely any references of the functions that triggered the error. As a consequence, we have 2 backtraces now when zellij crashes: One from `anyhow` (that is implicitly attached to anyhows error reports), and one from the custom panic handler (which is displayed through `miette`). * utils/errors: Separate stack traces in the output of miette. Since we record backtraces with `anyhow` now, we end up having two backtraces in the output: One from the `anyhow` error and one from the actual call to `panic`. Adds a comment explaining the situation and another "section" to the error output of miette: We print the backtrace from anyhow as "Stack backtrace", and the output from the panic handler as "Panic backtrace". We keep both for the (hopefully unlikely) case that the anyhow backtrace isn't existent, so we still have at least something to work with. * server/screen: Remove calls to `fatal` and leave the `panic`ing to the calling function instead. * server/screen: Remove needless macro which extended `active_tab!` by passing the client IDs to the closure. However, this isn't necessary because closures capture their environment already, and the client_id needn't be mutable. * server/screen: Handle unused result * server/screen: Reintroduce arcane macro that defaults to some default client_id if it isn't valid (e.g. when the ScreenInstruction is sent via CLI). * server/tab/unit: Unwrap new results |
||
|---|---|---|
| .. | ||
| assets | ||
| src | ||
| Cargo.toml | ||