Warp 拒绝处理程序的典型示例是
async fn handle_rejection(err: Rejection) -> Result<impl Reply, Infallible> {
但是,Result<ok, err>这样的错误是无误的并且永远无法达到的优点是什么?为什么不只返回一个impl Reply?
Warp 拒绝处理程序的典型示例是
async fn handle_rejection(err: Rejection) -> Result<impl Reply, Infallible> {
但是,Result<ok, err>这样的错误是无误的并且永远无法达到的优点是什么?为什么不只返回一个impl Reply?
它通常意味着以下两种情况之一:
该函数是特征的一部分,特征声明表明该方法可能失败并返回一个Result<T, E>. 现在,该特征的某些实现可能碰巧没有失败路径,并且Infallible对E.
一个标准库的例子就是FromStrtrait。FromStr在实施时显然会失败u32,但在实施时不会失败String。因此impl FromStr for String用于std::convert::Infallible其错误情况。
该函数将在期望有错误函数的上下文中使用。
在您的示例中就是这种情况。handle_rejection被传递给warp::Filter::recover,它需要一个可出错的函数。这是有道理的,因为并非所有错误都是可恢复的,因此recover可能仍需要处理这些错误。
现在,这是一个恰好能够处理所有错误的玩具示例,因此使用Infallible.