Skip to content
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

Fix unwraps in Client #12

Closed
wants to merge 2 commits into from
Closed

Fix unwraps in Client #12

wants to merge 2 commits into from

Conversation

rustaceanrob
Copy link
Contributor

Feel free to edit any one of these

In the initialization of a Client there is an unwrap that I am not sure what to do with besides maybe throwing a specific error to the user that something went wrong with the environment variables or project config.

I added an additional unwrap_or so the entire initialization of the client has default values, but this behavior might not be desired and can be removed if no user_agent should throw an error.

Lastly, if a lock can't be acquire on the Mutex then another thread is using it, and I think the behavior should be the cache does not change, and there is no error. (as opposed to the unwrap)

@rustaceanrob rustaceanrob temporarily deployed to infisical-test-workspace January 13, 2024 08:40 — with GitHub Actions Inactive
Copy link
Collaborator

@DanielHougaard DanielHougaard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments, good work!

@@ -20,7 +20,7 @@ pub struct Client {

impl Client {
pub fn new(settings_input: Option<ClientSettings>) -> Self {
let settings = settings_input.unwrap();
let settings = settings_input.unwrap(); // show an error to set the .env? Not actually sure how this throws
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would honestly say that it's alright for it to throw a panic here. This would happen during the client initialization, if no settings or invalid settings are passed. Since we can't return a normal error, a rust panic would be alright here.

What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an expect could be a good option because the SDK bindings will show the panic message even in Swift, Kotlin, etc. With a short message it might help point the user in the right direction.

@rustaceanrob rustaceanrob temporarily deployed to infisical-test-workspace January 17, 2024 04:14 — with GitHub Actions Inactive
@rustaceanrob
Copy link
Contributor Author

I tried making an edit straight from github and screwed up the commit haha. Will make a new PR removing that function.

@rustaceanrob rustaceanrob deleted the client-unwraps branch January 17, 2024 04:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants