DEV Community: Greptime
·
大型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这样的复杂系统中组织不同类型的错误，从错误的定义到如何记录错误或向最终用户呈现错误。
🎯
关键要点
- 本文讨论了Rust错误处理的实践，特别是在GreptimeDB中的应用。
- 主题包括构建更便宜但更准确的错误堆栈、在大型项目中组织错误以及如何将错误打印到日志和最终用户。
- Rust的错误处理以Result<T, E>枚举为中心，E通常扩展std::error::Error。
- 开发者通常会为项目定义自定义错误，以表达特定的应用错误信息。
- 在GreptimeDB中，选择使用snafu库来构建错误系统，以便于定义和组合错误类型。
- 设计目标是构建一个能够提供更多上下文信息的错误报告，以便于调试和理解错误发生的原因。
- 系统回溯虽然可以提供调用栈信息，但会消耗大量CPU和内存，且包含许多无关信息。
- 虚拟用户堆栈是用户代码定义和构建的，能够提供更清晰的错误传播路径。
- 错误信息的呈现应考虑最终用户的需求，避免过于技术化的细节。
- 最终的错误消息格式应为：KIND - REASON ([EXTERNAL CAUSE])，以便于用户理解。
🏷️
标签
➡️
