rust - 期权类型和提前返回。 is_none() 时返回错误

Question

使用匹配(如 bar)似乎是一种常见的方法..

#[derive(Debug)]
pub enum MyErrors {
    SomeError,
}

fn foo(x: Option<u64>) -> Result<u64, MyErrors> {
    if x.is_none() {
      return Err(MyErrors::SomeError);
    } 

    // .. some long code where more options
    // are checked and matched 
    // The ok here is just so the code is simple and compiles
    Ok(x.unwrap() * 2)
}

fn bar(x: Option<u64>) -> Result<u64, MyErrors> {
    match x {
        None => {
            return Err(MyErrors::SomeError)?;
        }
        Some(v) => {
           // .. some long code where more options
           // are checked and matched 
           // The ok here is just so the code is simple and compiles
           Ok(x.unwrap() * 2)
        }
    }
}


fn main() {
    foo(Some(1));
    bar(Some(2));
}

但是，早期返回(例如在 foo 中)显着减少了代码的嵌套程度。如果必须多次解包选项或返回错误，则像 bar 这样的代码会非常嵌套...

在选项为空的情况下提前返回错误的推荐做法是什么？

Answer 1

如果由于内部逻辑复杂而不需要较长的方法链，仍然有一些可读性低缩进的选项。

ok_or 和 ?

我们可以将 Option 转换为带有所需错误的 Result，然后立即使用 ? 运算符将其解包。这个解决方案可能提供了尽可能少的缩进，并且可以很容易地用于“展开”多个 Option。

fn bar1(x: Option<u64>) -> Result<u64, MyErrors> {
    let x = x.ok_or(MyErrors::SomeError)?;
    // A lot of stuff going on.
    Ok(x * 2)
}

这将评估 ok_or 中的错误，而不管它是否会被实际使用。如果此计算代价高昂，则延迟产生错误的 ok_or_else 会更高效 ( related question )。

如果让

如果嵌套，此解决方案仍会导致代码阶梯式上升，但如果更多涉及 else 分支逻辑，则可能更合适。

fn bar2(x: Option<u64>) -> Result<u64, MyErrors> {
    if let Some(x) = x {
        // Lot of stuff here as well.
        Ok(x * 2)
    } else {
        Err(MyErrors::SomeError)
    }
}