advance/errors

[giscus[bot]]

advance/errors

https://course.rs/advance/errors.html

[Rustln]

[sunface]

我有个大胆的想法，建议直接贡献到内容中

[Rustln]

哈哈，好好好~~，我删了这个。。。

[themanforfree]

关于如何选用 thiserror 和 anyhow 只需要遵循一个原则即可：是否关注自定义错误消息，关注则使用 thiserror（常见业务代码），否则使用 anyhow（编写第三方库代码）。

这个位置是写错了吗，还是说我理解有误。
在写第三方库的时候才更需要 thiserror 这样的自定义错误类型吧。

[sunface]

@Rustln PR 来问题了 🤣

[Rustln]

首先，这是官方的原话：https://crates.io/crates/thiserror

另外，因为我们开发第三方库时往往只有顶级 pub 函数/方法才需要抛出错误消息，底层（非公开）的代码大多采用 ? 传播方式，通常交由使用者去处理，也避免了二次错误处理。

[themanforfree]

感谢解答，
但我还是有些不太理解。

如果你想要设计自己的错误类型，同时给调用者提供具体的信息时，就使用 thiserror，例如当你在开发一个三方库代码时。如果你只想要简单，就使用 anyhow，例如在自己的应用服务中。

关于如何选用 thiserror 和 anyhow 只需要遵循一个原则即可：是否关注自定义错误消息，关注则使用 thiserror（常见业务代码），否则使用 anyhow（编写第三方库代码）。

这两段话似乎相互矛盾了，前者说 thiserror 适合开发第三方库，后者却反过来了，变成 anyhaw 用来编写第三方库代码。

我的想法是 anyhow 可以更方便的向上传递错误，但传递的过程中会丢失原本错误的类型，只会留下错误信息，而对于第三方库而言，更需要提供自己的错误类型交给调用者判断，而不是向上传递一个只有信息却丢失类型的错误，这种情况应该更适合thiserror。

[yAntPower]

是的上面的两段写反了，看原文的意思就是 thiserror适合第三方库，对应的anyhow适合应用服务

[zhangdekui]

#[derive(thiserror::Error, Debug)]
enum MyError {
#[error("Environment variable not found")]
EnvironmentVariableNotFound(#[from] std::env::VarError),
#[error(transparent)]
IOError(#[from] std::io::Error),
}

我不信强迫症内心毫无波澜

[lihongtao1024]

这种写法我宁愿自己实现

[NicholasFirst]

对于返回的Result, 看到返回值有时候写作 Result<T>, 而有时候又写作 Result<T, E>, 是封装了Result 还是有其他原因比较疑惑, 有大佬可以指点一下么?

[yhio]

https://github.com/dtolnay/anyhow/blob/master/src/lib.rs#L407

[fung-hwang]

是一种常见的别名。通常在一个库中只有一种Error类型（比如serde_json的serde_json::Error），函数返回Result<T, E>的E总是这个类型，所以就省略了。

引用一段其他地方的论述：
After that, define a type alias for Result that includes your concrete error type, so that you don't need to type Result<T, YourErrorType> everywhere, but can simply type Result. This is a common Rust pattern.

[sukanka]

个人对这一段代码的理解: 采用短路求值的理解方式. 下面用 Option 表示 Some 或者 None

  assert_eq!(s1.or(s2), s1); // Some1 or Some2 = Some1
  assert_eq!(s1.or(n), s1);  // Some or None = Some
  assert_eq!(n.or(s1), s1);  // None or Some = Some
  assert_eq!(n.or(n), n);    // None1 or None2 = None2

前面两个都是 Some1 or Option 的形式, 由于是 or 运算,当左边已经是 Some 了,右边不管是什么,结果都是 Some, 因此可以直接返回 左边(即 Some1), 如果右边是一个复杂的表达式的时候,就不用计算右边. (其实就是 true or RHS =true)

后面两个是类似的, None or Option 的形式,由于这里还是 or, 左边是 None, 那么结果取决于右边的 Option, 因此直接返回右边的 Option 也是很合理的. (其实就是 false or RHS=RHS)

然后 and 也是类似的,

  assert_eq!(s1.and(s2), s2); // Some1 and Some2 = Some2
  assert_eq!(s1.and(n), n);   // Some and None = None
  assert_eq!(n.and(s1), n);   // None and Some = None
  assert_eq!(n.and(n), n);    // None1 and None2 = None1

前两个 是 Some and Option, 这里是 and, 左边是 Some, 那么取值由右边确定,所以直接返回右边 (true and RHS=RHS)

后面两个是 None and Option, 这里 and 左边是 None 结果不管怎样都是 None,所以返回 None 就完事了 (false and RHS=false)

[zhouhaoan]

晕了，这是什么。。

[wuxianao]

为什么不讲一下anyhow得with_context,这样可以很快简化代码（建议）

[sunface]

好建议。

反建议一个：大佬能否提一个 PR ：）

[wuxianao]

已经提了, 不过不是大佬, 只是结合文章翻译了一下官方的文档而已 ：P. 如有错漏还望指正.

[Ryu2u]

为什么，这段代码在main中可以编译，但是但单元测试中就没办法编译

fn render() -> Result<String, Box<dyn std::error::Error>> {
    let file = std::env::var("MARKDOWN")?;
    let source = read_to_string(file)?;
    Ok(source)
}
// dyn error
#[test]
fn test_dyn_error() -> Result<(), Box<dyn std::error::Error>>{
    let html = render()?;
    println!("{}", html);
    Ok(())
}

他会报String没有实现Read特征

error[E0277]: the trait bound `String: std::io::Read` is not satisfied
     |
194  |     let source = read_to_string(file)?;
     |                  -------------- ^^^^ the trait `std::io::Read` is not implemented for `String`
     |                  |
     |                  required by a bound introduced by this call
     |

[iamtaojin]

我复制你的这段代码诚了诚，是可以通过的。

[iamtaojin]

我复制你的这段代码试了试，是可以通过的。

[Ryu2u]

使用thiserror需要添加依赖啊，文章中怎么没提到

[sunface]

额，其实有提到，不过可能没那么明显：

上面的第二种方式灵活归灵活，啰嗦也是真啰嗦，好在 Rust 的社区为我们提供了 thiserror 解决方案，下面一起来看看该如何简化 Rust 中的错误处理。

[CynicalHeart]

归一化使用特征对象那一节中：

“一个类型就算不实现 Error 特征，它依然可以在 Result<T, E> 中作为 E 来使用，此时这种特征对象的解决方案就无能为力了。”

啊？ 特征对象不就是接收实现了同个特征的对象而存在的吗，类似多态，不实现Error类型，怎么匹配上的。我不能理解了。