rust - 使用 .unwrap() 应该被视为不好的做法吗?

标签 rust error-handling

看到 Improve this question 下的评论,让我想知道 - 使用 unwrap() 是否应该被视为不好的做法?

在我看来,有时展开是有意义的。至少在这两种情况下:

  1. 我们知道 Option 值不能是 None ,因为我们已经在代码的前面处理过这种情况。一个例子:
if o.is_none() {
    // do some stuff here...
    return ...;
}
// ...
o.unwrap()   //  <--- Here I do NOT expect a None
  • 如果我们开发一个简单的短期工具,无论哪种方式都会以错误结束,依靠 panic 而不是“适当的”错误处理(使用 Result? 等)可以或多或少地简化代码。
  • 显然,有时依赖 unwrap() 可能弊大于利,因此我是否应该始终避免使用 unwrap() 对我来说并不是很明显?如果没有,什么时候可以使用 unwrap()

    最佳答案

    We know an Option value cannot be None, because we have already checked that case, earlier in the code. An example:

    if o.is_none() {
        return ...;
    }
    // ...
    o.unwrap()   //  <--- Here I do NOT expect a None
    

    虽然在某些情况下这是不可避免的,但处理这种情况的“正确”方法是使用模式匹配,例如

    let o = if let Some(o) = o {
        o
    } else {
        return o;
    }
    

    或者类似的东西。

    在某些情况下,“展开”是不必要的,但在这种情况下,在生产软件中,我会使用带有非通用解释的 expect ,或者明确的 panic!并附有假设的文档。

    If we develop a simple short-lived tool, which is simply gonna end on error either way, relying on panics instead of "proper" error handling (with Result, ?, etc.) could simplify code, more or less.

    这不会使其成为“良好实践”,只会使其成为“我不关心在这种情况下的不良实践”。

    这是一个完全合理的立场,但这不是好的做法。

    关于rust - 使用 .unwrap() 应该被视为不好的做法吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/69316181/

    相关文章:

    oop - 为什么 Rust 不支持 trait 对象向上转换?

    node.js - 处理Node.js中的错误

    rust - 如何包装一个返回 Future 的闭包,而不是同步?

    rust - rust-具有特征的泛型函数的返回类型

    node.js - 如何处理express nodejs中的body-parser错误

    node.js - 在 Express 和 Restify 中处理 uncaughtException

    flash - 如何检测由于 Flash 崩溃导致的 YouTube iFrame 故障?

    java - ClassCastException : Proxy0 cannot be cast to interfaces. 患者

    rust - 如何编译 Rust 代码以在 Raspberry Pi 2 上运行?

    rust - HashMap Entry API 的生命周期/借用问题