如何追溯错误结果的原因？答案

【问题标题】：How to trace the cause of an error result?如何追溯错误结果的原因？
【发布时间】：2017-07-05 16:07:51
【问题描述】：

在编写使用Result 类型的代码时，您可能希望用户和开发人员有不同的行为。

在编写优雅处理错误的应用程序时，最好使用Result。
在开发过程中，您可能希望“捕获”错误以查看是哪一行代码创建了错误，或者在创建 Err 值时获取堆栈跟踪。

如果你犯了一个独特的错误，搜索它并不难，但如果错误来自标准库，则错误可能非常普遍。

例如，如果不手动将每个file.read()? 更改为file.read().unwrap()，就不可能知道哪个read 命令导致了意外的文件结束。

有没有一种方便的方法可以从 Result 获取堆栈跟踪？

一个弱但可行的解决方案可能是制作一个用于阅读的宏，read_in_release_unwrap_in_debug!(file, data)...但这感觉很尴尬。

我有一个文件阅读器，有很多 read 调用，但一个失败。我不确定是哪个。在运行时，我想将结果推送回调用者。为了调试，我希望停止失败的读取调用或以某种方式让我知道它的行号。

【问题讨论】：

标签： error-handling rust

【解决方案1】：

结果本身没有任何回溯信息，但您可以将其添加到自定义错误类型中。

error_chain crate 是一个为您生成错误类型的示例，当设置了RUST_BACKTRACE 环境变量时，您可以免费获得回溯生成。

您也可以直接使用backtrace 库并自己做。

【讨论】：

【解决方案2】：

如果您使用anyhow，您可以免费获得这个！问题是您需要每晚使用并启用环境变量：

RUST_BACKTRACE=1 cargo +nightly run

This is the tracking issue for stabilisation 和 a PR to stabilise it。看起来在稳定之前是否需要在 no_std 中工作或类似的事情存在一些分歧。

【讨论】：

【解决方案3】：

我用easy-error crate 解决了这个要求，而error-chain crate 也可以。

使用easy-error中定义的Result作为返回类型，然后使用context方法转换其他Result类型。

最重要的是将信息传递给带有行号的context方法。

use easy_error::{Result, ResultExt};
use std::path::PathBuf;

fn test_open() -> Result<()> {
    let mut p = PathBuf::from(env!("CARGO_MANIFEST_DIR"));
    p.push("resources/test/songs.json");
    File::open(p).context(format!("{}:{}", file!(), line!()))?;
    Ok(())
}

为避免一直输入format!("{}:{}", file!(), line!())，请定义一个宏：

#[macro_export]
macro_rules! code_loc {
    () => {
        format!("{}:{}", file!(), line!())
    };
}

最后的代码是：

File::open(p).context(code_loc!())?;

【讨论】：