-
Notifications
You must be signed in to change notification settings - Fork 5
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 and print error instead of panic when passing nonexistent context #51
Conversation
Hi and welcome!
That makes me super happy to hear! I'm using it every day as well so this improvement is a really good idea!
Since it can only be one error type at a time I think this is the correct choice 👍
I think this is a great addition and addresses something I haven't noticed 😅, I mostly use the select list and the backwards history, so big thank you for this PR! I will approve it since it's super nice by itself but you got me thinking about how to scale this, using the enum as is right now would scale great for context error but less for the modes, namespace or config reading, so if you don't mind, I might extract it to a separate file and make the enum name more generic while keeping them specific to the error to replace all eprint that we use today and add elsewhere, Or do you prefer that everyone creates their own custom errors? Also, what would you think of having a similar error message as |
You can ignore the test not working, I think it's bugged for PR:s |
Yes, don't hesitate to adapt it to the structure that makes sense for your future plans. Having it in a separate If I understand your questions correctly, you're weighing using one "global" Error enum vs. specific enums for the different modes?
Great idea, this will be the most familiar for users 👍
I think it's because the Or, assuming the contents of the secret are not actually confidential, the test kubeconfig could be provided inline or as a repository variable (reference) instead? |
Right, that makes sense, removing the secret in those jobs should be enough probably, it's just as you guessed a dummy value. I haven't tried thiserror yet, did enjoy using error_context crate the other day but will try thiserror out and compare! BTW! If you have any ideas on new features or changes in existing ones please let me know! |
Description
Currently, when trying to pass a context that does not exist in the configured
KUBECONFIG
, e.gkc foo
orkubesess context -v foo
, the program panics:This doesn't tell the user what went wrong and makes what is just a user error look like a bug.
To fix this,
set_context
now returns aResult<(), SetContextError>
, which is appropriately handled. If there is an error, the program will exit with a non-zero exit code and report the error on stderr (similarly to the error handling incommands::selectable_list
). The kubeconfig variable will not be changed (because of the non-zero exit code).Fixed behaviour:
❯ kc foo Error: Couldn't find context foo
Implementation hints / Considerations
thiserror
could make the error implementation more terse, but that adds another depedency that is not needed at this point. It's only 12 lines as is.Looking forward to your feedback :)
Also thanks for creating kubesess, I use it everyday and it makes my life easier, particularly with direnv it's a charm
Type of change
How Has This Been Tested?
kubesess
and the provided shell scriptsTest Configuration:
Linux 6.6.4-arch1-1
Intel i7-1260P
stable-x86_64-unknown-linux-gnu
rustc 1.70.0
Checklist: