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

Improve request parameter ergonomics. #79

Merged
merged 2 commits into from
Aug 22, 2022
Merged

Improve request parameter ergonomics. #79

merged 2 commits into from
Aug 22, 2022

Conversation

jbearer
Copy link
Member

@jbearer jbearer commented Aug 19, 2022

  • integer_param has a polymorphic return type, inferred from the
    calling context
  • add getters for optional parameters that return Option or
    Result so that request handlers can easily distinguish
    between error cases and "not provided" cases
  • add typed getters for boolean params

@jbearer jbearer requested a review from nyospe August 19, 2022 23:43
@jbearer jbearer self-assigned this Aug 19, 2022
* `integer_param` has a polymorphic return type, inferred from the
  calling context
* add getters for optional parameters that return Option or
  Result<Option> so that request handlers can easily distinguish
  between error cases and "not provided" cases
src/request.rs Outdated
self.opt_param(name)
.map(|val| {
val.as_integer().context(IncorrectParamTypeSnafu {
name: name.to_string(),
Copy link
Contributor

Choose a reason for hiding this comment

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

So, one way this could fail is if the TryFrom<u128> fails. As I recall, the Snafu can incorporate the original error... is extracting it going to give us enough information to match the old IntegerOverflow case? Can we include the value of the enum as well as its type somehow?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good point. I think the correct way to handle this is to have all the as_* functions return Result<_, RequestError> rather than Option<_>. These functions only ever fail if a conversion, fails, so there is no reason not to return an error in those cases. Then the *_param functions can just propagate the error.

Copy link
Contributor

@nyospe nyospe left a comment

Choose a reason for hiding this comment

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

Overall much nicer. I did make a note about what appears to be a reduction in provided information in an error case, that might be good to capture somehow.

@jbearer jbearer merged commit 0ab847d into main Aug 22, 2022
@Ancient123 Ancient123 deleted the feat/params branch November 29, 2022 15:59
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