Rust:Structuring and handling errors in 2020学习笔记_thiserror anyhow 那个用在application-CSDN博客

本文链接：https://blog.csdn.net/htyu_0203_39/article/details/106336635

Rust: Structuring and handling errors in 2020- 学习笔记

直接上菜，首先介绍两个新的Crate用于Rust Error处理，anyhow 和thiserror, 其代表Rust Error处理的最新探索成果! anyhow面向Application应用程序开发， thiserror面向Library开发，为什么一个Rust Error处理需要分成两个Crate来处理呢？！ 理由如下：

(1) 库应专注于生成有意义的结构化错误类型/变体。这允许应用程序轻松区分各种错误情况。

(2) 应用程序主要消化错误。

(3) 库需要将错误从一种类型转换为另一种类型。比如：将底层IO错误封装进本库提供的高级错误，这样调用者才能区分此底层IO错误具体来自于那个库。

(4) 库在更改错误或创建新错误时必须小心，因为这些错误很容易为调用者引入破坏性更改。所以要求库可以更容易地更改和新建错误，同时尽可能避免祸及调用者。

(5) 库返回错误，而应用程序需要决定这些错误是否格式化以及如何显示给人。

(6) 应用程序可能还希望分析和检查错误，例如将错误转发到异常跟踪系统，或者在认为安全时重试操作。

(7) 库的pub API应该始终使用std::Result和自定义Error 类型(并且它impl了std::error::Error Trait) ，而failure::Fail这类Rust Error处理Crate没有能与Rust原生的Error处理很好地融合，独自创造了一套，也难以很好的和用户代码相融合，增加了用户学习负担。

总结：基于以上理由，将错误处理分为两个crate就非常必要了！同时提炼出优质Rust Error处理crate的特性： A. 可以与Rust原生Error处理很好融合。B. 可以与用户代码很好地融合，最好是不漏踪迹，不污染用户代码。 C. 极大地降低学习和使用负担，最好零负担。 D. 非常容易更改和新建错误，不会导致调用者破坏性修改代码。 E. 可以backtrace, 清晰表达错误类型、源头和传播路径。 F. 可以给每个错误以人性化的可读信息。G. 灵活有效的错误分析、检查、转发、重试机制。

【详细内容请看】：https://nick.groenen.me/posts/rust-error-handling/