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

WIP A Result can be a Reply #740

Closed
wants to merge 1 commit into from
Closed

Conversation

kaj
Copy link
Contributor

@kaj kaj commented Nov 5, 2020

Provide impl Reply for Result<T, E> where both T and E implements Reply. This impl makes no difference between an Ok and an Err, but calls into_response for the contained data of either. If an error should be logged, that is the responsibility of the Reply impl on the E type.

This is testing my suggestion #712 (comment) .

To be really useful, it needs a way to use async fn foo(...) -> impl Reply as an handler. Filter .map does not do async while .and_then needs a Resule<impl Reply, Rejecttion>. Is there a middle version?

Provide `impl Reply for Result<T, E>` where both `T` and `E`
implements Reply.  This impl makes no difference between an Ok and an
Err, but calls `into_response` for the contained data of either.  If
an error should be logged, that is the responsibility of the `Reply`
impl on the `E` type.
@kaj kaj marked this pull request as draft November 5, 2020 21:36
@kaj
Copy link
Contributor Author

kaj commented Nov 6, 2020

Hm. Turns out that a) this is a duplicate of #458 and b) that PR also includes the FilterBase::map_async functions that makes it really useful and convenient.

Only problem with that PR is that it is from February and have merge conflicts. But they should be solvable.

@kaj kaj closed this Nov 6, 2020
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.

None yet

1 participant