Infallible Result 的重点是什么，而不仅仅是返回 Ok() 分支？

问题描述

canonical example of a Warp rejection handler 是

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

但是 Result<ok,err> 的优势是什么，使得错误是绝对可靠的并且永远无法达到？为什么不直接返回一个 impl Reply？

解决方法

通常意味着以下两种情况之一：

• 该函数是特征的一部分，特征声明表明该方法可能会失败并返回 Result<T,E>。现在，该 trait 的一些实现可能碰巧没有失败路径，并为 Infallible 使用类似 E 的类型。

  这方面的一个标准库示例是 FromStr 特征。 FromStr 在 u32 上实现时显然会失败，但在 String 上实现时不会。因此 impl FromStr for String 使用 std::convert::Infallible 作为其错误情况。

• 该函数将在期望函数易出错的上下文中使用。

  您的示例就是这种情况。 handle_rejection 被传递给 warp::Filter::recover，它期望一个容易出错的函数。这是有道理的，因为并非所有错误都可以恢复，因此 recover 可能仍需要处理这些错误。

  现在，这是一个玩具示例，恰好能够处理所有错误，因此使用 Infallible。