kubesess icon indicating copy to clipboard operation
kubesess copied to clipboard

Replace process:exit in functions with Result + error handling

Open nicmr opened this issue 1 year ago • 5 comments

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
    1. 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
    2. 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 return Result<(), Error> (or Option<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
  • 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

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

nicmr avatar Jan 30 '24 15:01 nicmr