kubesess
kubesess copied to clipboard
Replace process:exit in functions with Result + error handling
Description
Hi Rami, I hope you've had a good start into 2024 :) I'm back with another PR on error handling.
- Currently, some methods simply call
std::process::exit
when encountering an error, which can cause problems- It immediately exits the program and does not call any destructors (currently probably not a problem, but might in the future) like a panic would
- More importantly, it makes it hard to tell if a given function will cause the program to terminate, e.g. just reading the signature of a function
pub fn selectable_list(input: Vec<String>) -> String
does not tell you if it can cause the program to terminate, which can be very surprising to developers and requires you to always look at the implementation of a function.
- They also immediately print an error message, which makes it hard to wrap the error message with additional information, for example why the function was called
I'm looking forward to your feedback :)
Fixes # -
Type of change
- Add thiserror crate to make the error types less verbose
- Add
src/error.rs
module for error types - Fallible functions in
src/modes.rs
now returnResult<(), Error>
(orOption<T>
where appropriate) - Error messages are now defined on the error type
- Errors are now wrapped with the context or have the error context as a field where appropriate
Changes from a user perspective:
Only error messages have changed.
- Failing to make a selection with skim
- old:
No item selected
- new (context):
error: no item selected when prompted to select context
- new (namespace):
error: no item selected when prompted to select namespace
- old:
- Trying to select a context that doesn't exist (
kc foo
)- old:
error: no context exists with the name: foo
- new:
error: failed to set context: no context exists with the name foo
- old:
How Has This Been Tested?
- [x] Manual end-to-end testing
Test Configuration:
- Firmware version:
- Hardware:
- Toolchain:
- SDK:
Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [x] Any dependent changes have been merged and published in downstream modules