错误处理

背景与问题界定 在开发一个多层Rust服务（配置中心SDK + 核心引擎 + gRPC API层）的过程中，不同层次的错误处理方式出现了显著的不一致性。底层SDK返回io::Error和自定义枚举错误；引擎层将这些底层错误包装成自己的EngineError；API层又需要将引擎错误映射为gRPC状态码。随着层数的增加，错误类型的转换和传播路径变得混乱——有的地方用Box<dyn Error>做类型擦除，有的地方用自定义枚举包裹，被调函数的错误被直接unwrap或expect，导致线上panic。更棘手的是，需要追踪一个错误的完整来源链（例如是"文件不存在"→“配置加载失败”→“引擎初始化终止”→“服务注册失败”），但当时的错误包装方式丢失了上下文信息。 目标拆解与工程约束 库与应用的错误处理分离：底层库应该定义精确的错误类型（自定义enum），让调用者可以用match或map_err做程序化处理。而上层应用更适合使用anyhow的anyhow::Error做类型擦除和上下文添加。但库如果依赖了anyhow，所有调用方都被迫进入anyhow生态——这是一个错误的设计决策。 错误链的上下文保持：source() 方法定义了错误链，但实现时经常遗漏 #[source] 或 #[from] 标注，导致链断裂。需要保证每层错误包装都保留底层错误的引用，且不破坏Send + Sync约束。 panic vs 返回值决策：对于不可恢复的错误（内存分配失败、断言失败），panic是合理的；但对于可预期的外部故障（网络超时、配置缺失），必须使用Result。问题在于"可恢复"的边界在团队中没有统一认识，导致一些可以优雅降级的场景直接panic了。 跨Crate的错误兼容性：多个Crate定义了各自的错误类型，但它们之间经常需要互转。手动实现From<T>的每个组合是O(n²)的工作量。需要统一错误类型的设计模式，减少手动转换的重复劳动。 方案设计 我们采用"分层错误模型"，在每个层级的边界上使用不同的错误处理策略： 底层SDK Crate：使用thiserror 定义精确的 #[derive(Error)] enum。每种失败原因是一个variant，携带相关的结构化数据。通过#[from] 自动生成From实现，通过#[source] 标注底层错误。 #[derive(Error, Debug)] pub enum ConfigStoreError { #[error("IO error reading config from {path}")] IoError { #[source] source: io::Error, path: PathBuf, }, #[error("deserialization failed: {detail}")] DeserializeError { #[source] source: serde_json::Error, detail: String, }, #[error("configuration key `{key}` not found")] KeyNotFound { key: String }, #[error("watch stream terminated unexpectedly")] WatchTerminated, } 应用层：使用anyhow 统一错误载体。在调用底层库的边界上，使用context() 方法添加上下文信息，将底层的结构化错误转换为anyhow::Error。这样应用层代码不用关心错误的具体类型，只需记录错误链的每一个"发生了什么"的上下文。 use anyhow::{Context, Result}; fn load_and_sync() -> Result<ConfigSnapshot> { let store = ConfigStore::new() .with_context(|| "failed to initialize config store")?; let snapshot = store.load("app-config.yaml") .with_context(|| "failed to load config from store")?; sync_to_peers(&snapshot) .with_context(|| "failed to sync snapshot to peer nodes")?; Ok(snapshot) } API层：通过From<&anyhow::Error> 将anyhow错误映射为gRPC状态码或HTTP响应。关键设计是保留错误链各层的上下文信息，在日志中打印完整错误链（通过{:#}格式化）。 实施路径与关键决策 制定"错误处理策略文档"：明确规定：库代码必须使用thiserror的自定义enum；应用代码使用anyhow；API边界做错误映射。panic仅用于内部断言和不可恢复状态，所有外部可观测的失败必须通过Result返回。 使用eyre作为anyhow替代：在某些需要自定义报告格式的场景（如输出到Sentry、OpenTelemetry），使用eyre并自定义EyreHandler来捕获span信息。 禁止unwrap和expect（除了测试）与极小部分确认不会失败的地方：所有Result必须显式处理。通过clippy的clippy::unwrap_used lint强制。 验证指标与可持续迭代 迁移后线上panic频率从每千请求0.7次降为0次。错误日志的可追溯性提升——通过OpenTelemetry，每个错误的完整链被记录为span events，facilitate根因分析的效率提升60%。新增Crate必须遵循分层错误模型，通过CI中的cargo check --deny unwrap_used和自定义review检查。 ...

背景与问题界定 在一次微服务调用链路的故障排查中，一个下游超时错误经过了四层服务传递后，最终在入口层捕获到的错误信息是"internal error"——原始的timeout信息和调用栈全部丢失。开发团队花了两个小时通过日志关联才定位到根因。这个场景在微服务架构中并不罕见：错误在传播过程中被多次包装、吞没或降级，最终只剩下一个对排查毫无帮助的通用错误。 Go 1.13引入的errors.Is/As/Unwrap机制为错误链提供了语言级支持，但在实际工程中，错误处理远不止于"判断错误类型"。它涉及错误分类（业务错误 vs 系统错误）、错误分级（致命 vs 可重试）、错误传播（跨服务边界时如何携带上下文）以及错误的可观测性（结构化日志和告警）。更进一步的工程化实践还包括故障注入测试——主动模拟各种错误场景来验证系统的容错能力。 目标拆解与工程约束 错误类型必须分层且可穷举：错误分为基础设施错误（网络超时、磁盘IO）、框架错误（认证失败、限流触发）和业务错误（余额不足、库存不足）。每一层需要有明确的错误码范围和类型定义，避免跨层混合。 错误传播过程必须保留完整链路信息：错误从发生点到最终处理点可能经过多个goroutine和多个服务。需要确保每次wrap都附带足够上下文（操作名称、参数摘要、时间戳），同时不泄露敏感信息。 错误处理策略必须可配置：同一个错误在不同上下文中可能有不同的处理方式——DB超时在读取缓存时可能降级，但在写主库时必须fail-fast。需要策略模式来分离"错误检测"和"错误响应"。 故障注入必须安全且可观测：故障注入测试需要在非生产环境执行，但配置的模拟故障类型和比例需要与生产一致。注入的故障必须是可控的：有开始时间、结束时间和影响范围。 方案设计 核心方案构建在"错误沙盒"（Error Sandbox）概念之上。错误不再只是充当if err != nil的判断条件，而是携带了结构化的元数据： type AppError struct { Code string // 错误码，如"DB_TIMEOUT" Message string // 人类可读的错误描述 Op string // 操作名称，如"CreateOrder" Kind Kind // 错误大类：System / Business / Security Severity Severity // 严重级别：Fatal / Error / Warning Retryable bool // 是否可重试 Stack string // 调用栈（仅在内部传播时保留） Source string // 产生错误的服务/组件名 Timestamp time.Time // 错误发生时间 WrapErr error // 被包装的原始错误 } 错误的构建和检查通过工厂方法和断言函数完成： // 创建错误 func NewDBTimeoutError(op string, cause error) *AppError { return &AppError{ Code: "DB_TIMEOUT", Op: op, Kind: System, Severity: Error, Retryable: true, Source: "order-db", WrapErr: cause, } } // 错误断言 func IsRetryable(err error) bool { var ae *AppError if errors.As(err, &ae) { return ae.Retryable } return false } 故障注入方面，实现了一个基于接口的故障注入器。通过编译期开关和环境变量控制，在测试和非生产环境主动注入预定义的故障模式： ...

背景 Rust 的 Result 很强，但很多项目还是会遇到同一个问题： 错误被一路 ? 传上去 日志里只有一个模糊报错 出问题时不知道是哪个环节失败 这通常是错误分层没有做好。 一条实用原则 库层定义结构化错误类型 应用层补充上下文并统一输出 use thiserror::Error; #[derive(Debug, Error)] pub enum RepoError { #[error("record not found")] NotFound, #[error("db error: {0}")] Database(String), } use anyhow::{Context, Result}; pub async fn get_user_handler(id: i64, svc: &UserService) -> Result<UserDto> { let user = svc .find_user(id) .await .with_context(|| format!("get user failed, id={id}"))?; Ok(UserDto::from(user)) } 日志里要带可关联字段 只打印错误文本通常不够，至少带上： 请求 ID 用户或租户标识 关键资源 ID tracing::error!( request_id = %request_id, user_id = user_id, error = %err, "failed to get user" ); 总结 Rust 错误处理做得好，排障效率会明显提升。 ...

C++ 错误处理的痛 C++ 里错误处理方式一大堆，但没一个完美的： // 方式1: 返回值 + 特殊值 int get_value() { if (failed) return -1; // -1 是魔法值 } // 方式2: 异常 try { do_something(); } catch (const std::exception& e) { // 异常才是正文... } 异常的问题是：不知道会抛什么，不知道该不该 catch，析构函数里抛异常还会 std::terminate。 Rust 的错误哲学 Rust 把错误分为两类： 可恢复错误 → Result<T, E> 不可恢复错误 → panic! // 可恢复：用 Result fn read_file(path: &str) -> Result<String, std::io::Error> { std::fs::read_to_string(path) } // 不可恢复：用 panic fn main() { let v = vec![1, 2, 3]; v.get(10).expect("索引超出范围"); // 程序员的bug } 实战：错误处理的几种模式 1. 基本用法 use std::fs::File; use std::io::{self, Read}; fn read_config() -> Result<String, io::Error> { let mut file = File::open("config.toml")?; let mut contents = String::new(); file.read_to_string(&mut contents)?; Ok(contents) } fn main() { match read_config() { Ok(config) => println!("配置: {}", config), Err(e) => eprintln!("读取配置失败: {}", e), } } ? 操作符是灵魂——错误自动向上传播，不需要手写 match。 ...