-
Notifications
You must be signed in to change notification settings - Fork 967
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
Provide more data in Path
deserialization error
#574
Conversation
@pnehrer what do you think about this solution? |
79e32e4
to
774c21c
Compare
This looks great! Thank you so much for doing this 👍 |
This is a little too big for me to fully review. Is there such a thing as a rustdoc diff? 😄 From my glancing over the changes before I found the internal The general idea of this seems good, the only other thing I can say is I think you missed documenting the rejection type rename in the changelog. |
I've been thinking that we should have more tests for this since generating the right errors is an important part of the API. So I'm gonna write some tests for the stuff in this PR. That might also make things slightly easier to review because you can more easily see the behavior of things without having to internalize how all the code works.
Hehe yeah for sure its over engineered but also kinda nice I think. But yeah as you say its a small internal API that we can always change later if we want.
Good catch! I'll fix that later. |
1f0877f
to
1fdd265
Compare
@jplatte I've added some tests now and found a few things that could be improved. |
Fixes #559
This changes the error returned by
Path
if deserialization fails, to provide more data about the exact error. This allows users to convert into their own errors. It also makes the default error messages more precise.Also added a new example showing how to customize the error https://github.com/tokio-rs/axum/blob/path-error/examples/customize-path-rejection/src/main.rs. Its the exact same approach as this but can't hurt having an example for it.
TODO