Evan Carroll
Evan Carroll

Reputation: 1

What is the point of an Infallible Result, over just returning the Ok() branch?

The canonical example of a Warp rejection handler is

async fn handle_rejection(err: Rejection) -> Result<impl Reply, Infallible> {

But what's the advantage of a Result<ok, err> such that the err is Infallible and can never be reached? Why not just return an impl Reply?

Upvotes: 11

Views: 6479

Answers (1)

mcarton
mcarton

Reputation: 30061

It usually means one of two things:

  • The function is part of a trait, and the trait declaration indicates that the method can fail and return a Result<T, E>. Now, some implementations of that trait might happen not to have a fail path, and use an Infallible-like type for E.

    A standard library example of this is the FromStr trait. FromStr can obviously fail when implemented on u32, but not when implemented on String. Therefore impl FromStr for String uses std::convert::Infallible for its error case.

  • The function is going to be used in a context that expects a fallible function.

    This is the case in your example. handle_rejection is passed to warp::Filter::recover, which expects a fallible function. This makes sense as not all errors are recoverable, therefore recover might still have to deal with these.

    Now, this is a toy example that happens to be able to handle all errors, and therefore use Infallible.

Upvotes: 21

Related Questions