大型Rust项目的错误处理——深入探讨GreptimeDB的实践
原文英文，约2700词，阅读约需10分钟。
📝
内容提要
本文讨论了Rust错误处理的实践，并分享了GreptimeDB中可能的未来工作。主题包括：（1）如何构建更便宜但更准确的错误堆栈以替代系统回溯；（2）如何在大型项目中组织错误；（3）如何以不同的方案将错误打印到日志和最终用户。GreptimeDB中的错误可能如下所示：0：Foo错误，位于src/common/catalog/src/error.rs:80:10；1：Bar错误，位于src/common/function/src/error.rs:90:10；2：根本原因，无效的表名，位于src/common/catalog/src/error.rs:100:10。Rust的错误处理以Result<T, E>枚举为中心，其中E通常（但不必要地）扩展std::error::Error。文章还介绍了如何在GreptimeDB这样的复杂系统中组织不同类型的错误，从错误的定义到如何记录错误或向最终用户呈现错误。
❓
Q&A
Rust中的错误处理是如何工作的？
Rust的错误处理以Result<T, E>枚举为中心，E通常扩展std::error::Error。
GreptimeDB是如何组织错误的？
GreptimeDB通过定义自定义错误类型，并使用snafu库来构建错误系统，以便于定义和组合错误类型。
在GreptimeDB中，如何记录和呈现错误信息？
GreptimeDB采用虚拟用户堆栈来记录错误信息，提供清晰的错误传播路径，并以用户友好的格式呈现错误。
为什么系统回溯在错误处理上存在局限性？
系统回溯消耗大量CPU和内存，并包含许多无关信息，难以快速定位错误源。
GreptimeDB中错误消息的最终格式是什么？
最终的错误消息格式为：KIND - REASON ([EXTERNAL CAUSE])，以便于用户理解。
如何在Rust项目中定义自定义错误？
开发者通常会为项目定义自定义错误，以表达特定的应用错误信息，通常使用thiserror或anyhow库。
🏷️
