在 Rust 生态系统中，错误处理是一个复杂而重要的话题。虽然社区提供了 thiserror、anyhow 等优秀的错误处理库，但在某些场景下，我们希望尽量减少外部依赖，仅使用标准库来实现健壮的错误处理。本文将深入探讨 Rust 无依赖错误处理的实现策略，并提供可落地的工程实践。
为什么选择无依赖错误处理？
安全性与供应链安全
在当今的软件开发环境中，供应链安全已成为不可忽视的问题。NPM 生态系统的依赖灾难给开发者敲响了警钟。Rust 虽然拥有相对健康的生态系统，但每个引入的第三方 crate 都增加了攻击面和维护负担。
使用标准库实现错误处理有以下优势：
- 代码所有权：你完全控制自己的代码，无需担心第三方库的维护状态或安全漏洞
- 审计便利：标准库代码经过严格审查和广泛测试，安全性有保障
- 依赖简化：减少依赖数量可以降低构建时间、二进制大小和潜在冲突
适应性与一致性
标准库提供了所有 Rust 开发者都熟悉的通用接口。几乎每个 Rust 项目都使用标准库，这意味着：
- 团队成员无需学习特定库的 API
- 代码更容易被其他开发者理解和维护
- 标准库的接口稳定且向后兼容
Rust 错误处理的基本原理
Rust 的错误处理基于 Result<T, E> 类型和 ? 操作符，这与传统的 try/catch 范式有本质区别。在嵌入式系统开发中，异常通常被禁止使用，因为需要保证时序确定性和避免未定义行为。
正如 LaurieWired 在安全关键嵌入式代码视频中提到的，Rust 通过返回码替代异常，为每个错误映射特定代码，并要求开发者在错误发生时立即处理。这种方式虽然增加了认知负担，但提供了更好的可组合性和确定性。
无依赖错误处理的实现策略
基础错误类型设计
最基本的自定义错误类型是一个枚举，它包装了可能发生的各种错误：
use std::{error::Error, fmt::{Display, Formatter}};
#[derive(Debug)]
pub enum DemoError {
ParseErr(std::num::ParseIntError),
}
impl From<std::num::ParseIntError> for DemoError {
fn from(error: std::num::ParseIntError) -> Self {
DemoError::ParseErr(error)
}
}
impl Error for DemoError {}
impl Display for DemoError {
fn fmt(&self, f: &mut Formatter) -> Result<(), std::fmt::Error> {
match self {
DemoError::ParseErr(error) => write!(
f,
"error parsing with {}", error.to_string()
),
}
}
}
这种实现虽然简单，但错误信息不够丰富，缺乏位置信息和上下文。
添加位置信息
为了在错误中包含发生位置，我们可以使用 panic::Location 和 #[track_caller] 属性：
use std::{
error::Error,
fmt::{Display, Formatter},
panic::Location,
};
#[derive(Debug)]
pub struct DemoError {
kind: DemoErrorKind,
location: &'static Location<'static>,
}
#[derive(Debug)]
pub enum DemoErrorKind {
ParseErr(std::num::ParseIntError),
}
impl From<std::num::ParseIntError> for DemoError {
#[track_caller]
fn from(error: std::num::ParseIntError) -> Self {
DemoError {
kind: DemoErrorKind::ParseErr(error),
location: Location::caller(),
}
}
}
impl Error for DemoError {}
impl Display for DemoError {
fn fmt(&self, f: &mut Formatter) -> Result<(), std::fmt::Error> {
match &self.kind {
DemoErrorKind::ParseErr(error) => write!(
f,
"my function had a parse error {} at location {}",
error.to_string(),
self.location.to_string()
),
}
}
}
现在错误信息会包含具体的位置，如 src/main.rs:37:26，大大提高了调试效率。
添加上下文信息
有时我们需要在错误中包含导致失败的输入数据。这可以通过 map_err 方法实现：
use std::{
error::Error,
fmt::{Display, Formatter},
panic::Location,
};
#[derive(Debug)]
pub struct DemoError {
kind: DemoErrorKind,
location: &'static Location<'static>,
}
#[derive(Debug)]
pub enum DemoErrorKind {
FirstNumberErr(String),
NextNumberErr(String),
}
impl DemoError {
#[track_caller]
fn new(kind: DemoErrorKind) -> Self {
DemoError {
kind: kind,
location: Location::caller(),
}
}
}
impl Error for DemoError {}
impl Display for DemoError {
fn fmt(&self, f: &mut Formatter) -> Result<(), std::fmt::Error> {
match &self.kind {
DemoErrorKind::FirstNumberErr(failed_input) => write!(
f,
"my function failed parse and had a first number input '{}' at location {}",
failed_input,
self.location.to_string()
),
DemoErrorKind::NextNumberErr(failed_input) => write!(
f,
"my function failed parse and had a next number input '{}' at location {}",
failed_input,
self.location.to_string()
),
}
}
}
fn my_function() -> Result<(), DemoError> {
let first_input = "3";
let my_number: i32 = first_input
.parse()
.map_err(|_|
DemoError::new(DemoErrorKind::FirstNumberErr(
first_input.into()
))
)?;
println!("{my_number}");
let next_input = "3^";
let my_number_two: i32 = next_input
.parse()
.map_err(|_|
DemoError::new(DemoErrorKind::NextNumberErr(
next_input.into()
))
)?;
println!("{my_number_two}");
Ok(())
}
这种实现提供了完整的错误信息：错误类型、失败的具体输入、发生位置。对于库的消费者来说，他们可以根据不同的错误类型采取不同的处理策略。
工程实践与最佳参数
错误类型设计模式
在实际工程中，建议采用以下设计模式：
- 分层错误类型：为不同模块或层次定义不同的错误类型
- 错误代码系统：为生产环境定义可追踪的错误代码
- 结构化错误数据：使用结构体而非简单枚举来承载丰富的错误信息
性能优化参数
无依赖错误处理在性能方面有几个关键参数需要考虑：
- 零成本抽象：确保错误类型的大小在编译时确定，避免动态分配
- 内联优化：对小型错误类型使用
#[inline]提示编译器进行内联 - 错误传播开销：使用
?操作符而非显式匹配，让编译器优化错误传播路径
监控与日志集成
在生产环境中，错误处理需要与监控系统集成：
- 错误分类：为不同严重程度的错误定义不同的处理策略
- 上下文保留：确保错误链中的上下文信息不被丢失
- 结构化日志：将错误信息以结构化格式输出，便于日志分析系统处理
与第三方库的对比
thiserror 的优势与局限
thiserror 通过过程宏大大简化了自定义错误类型的定义：
use thiserror::Error;
#[derive(Error, Debug)]
pub enum MyError {
#[error("failed to read config: {0}")]
ConfigRead(#[from] std::io::Error),
#[error("invalid config format: {0}")]
ConfigParse(String),
}
优势：
- 减少样板代码
- 自动生成
Display实现 - 支持
#[from]自动转换
局限：
- 引入了外部依赖
- 宏生成的代码可能难以调试
- 灵活性受限
anyhow 的适用场景
anyhow 适用于应用程序的错误处理，它提供了便捷的错误包装和上下文添加：
use anyhow::{Context, Result};
fn process_file(path: &str) -> Result<()> {
let content = std::fs::read_to_string(path)
.context(format!("failed to read {}", path))?;
// ...
}
适用场景：
- 快速原型开发
- 命令行工具
- 不需要精细错误类型的应用
编译时检查与安全保证
Rust 的强类型系统为错误处理提供了编译时保证。以下是一些重要的编译时检查策略：
错误穷尽性检查
使用 match 表达式时，Rust 编译器会强制处理所有可能的错误变体：
match result {
Ok(value) => process(value),
Err(DemoError::FirstNumberErr(input)) => handle_first_error(input),
Err(DemoError::NextNumberErr(input)) => handle_next_error(input),
// 编译器会确保所有变体都被处理
}
不可恢复错误标记
对于不可恢复的错误，可以使用 panic! 或 unreachable! 宏，但需要谨慎使用。正如 Cloudflare 事故所示，即使是受信任的输入也可能出错。
实际部署参数
错误处理配置
在生产环境中，建议配置以下参数：
- 错误重试策略：为可重试错误定义最大重试次数和退避策略
- 错误降级：定义错误发生时的降级行为
- 监控阈值：设置错误率阈值，触发告警
测试策略
无依赖错误处理需要更全面的测试：
- 错误路径测试：确保所有错误分支都被测试覆盖
- 错误信息验证：验证错误信息包含足够调试信息
- 性能基准测试：测量错误处理对性能的影响
结论
Rust 的无依赖错误处理虽然需要更多的手动工作，但提供了更好的控制性、安全性和性能。通过合理设计错误类型、利用标准库特性（如 #[track_caller] 和 panic::Location），我们可以构建既健壮又高效的错误处理系统。
在选择错误处理策略时，需要权衡以下因素：
- 项目的安全要求
- 团队的熟悉程度
- 性能约束
- 维护成本
对于安全关键系统、嵌入式设备或对依赖数量敏感的项目，无依赖错误处理是一个值得考虑的选择。对于快速开发的应用或原型，使用 thiserror 或 anyhow 可能更合适。
无论选择哪种策略，重要的是保持一致性，确保错误处理逻辑清晰、可维护，并且能够提供足够的调试信息来快速定位和解决问题。
资料来源
- Vincent's Blog - Rust Errors Without Dependencies: https://vincents.dev/blog/rust-errors-without-dependencies/
- Momori Nakano - Rust Error Handling: thiserror, anyhow, and When to Use Each: https://momori.dev/posts/rust-error-handling-thiserror-anyhow