错误处理进阶与错误类型设计
1. 这是什么
Rust 的错误处理进阶，关注的不再只是“会不会用 Result 和 ?”，而是：
- 错误应该分成哪些层次
- 什么时候该返回具体错误类型
- 什么时候该做统一封装
- 错误信息是给机器看的，还是给人看的
- 边界层和核心层的错误该如何区分
一句话理解：
- 初级错误处理是在“把失败传出去”
- 进阶错误处理是在“把失败设计清楚”
2. 为什么重要
小程序里，很多人会觉得：
unwrap()先跑通再说- 或者全部塞成字符串错误也能工作
但项目一旦变大，很快就会暴露问题：
- 调用方不知道失败到底是哪一类
- 日志里只有模糊文本，排查困难
- 底层细节泄漏到上层接口
- 用户提示、内部诊断、监控统计混在一起
错误处理设计的重要性在于：
- 它决定系统在失败时是否可维护
- 它决定边界层是否清晰
- 它决定调用方能不能做出正确分支处理
从工程角度看，错误设计几乎就是系统设计的一部分。
3. 先建立直觉
先把错误分成两层看：
- 事实层：到底发生了什么失败
- 接口层：这次失败要以什么形式暴露给调用方
比如：
- 底层事实可能是“配置文件不存在”“JSON 格式非法”“数据库超时”
- 上层接口可能只关心“启动配置加载失败”“请求处理失败”
所以错误处理不是把所有底层细节一路原封不动地往上传，而是要判断：
- 哪些信息该保留
- 哪些信息该聚合
- 哪些信息只适合日志，不适合暴露给外部
4. 核心内容
4.1 Result<T, E> 只是开始，不是终点
学 Rust 入门时，我们会知道：
- 成功返回
Ok(T) - 失败返回
Err(E)
但进阶阶段真正关键的问题变成：
E到底应该是什么
这才是错误设计的核心。
因为 Result 只是容器，真正表达系统边界的是错误类型本身。
4.2 错误类型不是越细越好，也不是越统一越好
很多人会走向两个极端：
极端一：所有错误都变成字符串
这样做短期省事，但问题是：
- 无法分类处理
- 无法稳定匹配
- 难以做上层逻辑分支
极端二：错误类型细到失控
如果每一层都暴露大量极细粒度错误，上层会非常痛苦：
- 错误链条过长
- 调用方知道了太多内部细节
- 模块边界变差
更好的思路是：
- 在模块内部允许更细
- 在模块边界做适度归并与抽象
4.3 错误类型本质上是在定义模块边界
这是最值得建立的工程直觉之一。
如果一个模块对外暴露的错误类型很乱，往往说明：
- 模块内部职责不清
- 边界没封装好
- 上层被迫理解太多下层细节
反过来，如果错误类型设计得好，通常意味着：
- 调用方能清楚知道有哪些失败类别
- 内部实现细节被合理隔离
- 错误语义和模块职责是对齐的
所以错误类型不是附属物，而是 API 设计的一部分。
4.4 什么时候该暴露具体错误，什么时候该封装
可以先建立一个很实用的判断：
- 模块内部协作：可以保留更具体的错误信息
- 模块对外边界：通常要做一定封装和统一
比如：
- 解析层可能区分缺字段、类型错、格式错
- 业务层可能只暴露“输入非法”
- HTTP 层可能进一步映射成 400 / 404 / 500
这并不是在“丢信息”，而是在按层组织信息。
真正细节仍然可以保留在：
- 日志
- source 链
- 调试信息
- 内部监控标签
4.5 “给用户看”和“给开发者看”的错误不是同一种东西
这是很多系统最常混淆的一点。
错误消息通常至少面向两类对象：
- 用户 / 调用方：需要清晰、稳定、可理解
- 开发者 / 运维：需要细节、上下文、排查价值
这意味着：
- 不能把底层 panic 风格信息直接暴露给外部用户
- 也不能只给开发者一句“失败了”
成熟的错误设计通常会区分：
- 对外语义
- 内部诊断
4.6 ? 运算符很方便，但会隐藏设计问题
? 极大提升了 Rust 错误传播的流畅度。
但初学者也容易因此忽略一个问题：
- 错误是怎么被转换的
- 当前这层到底是在直接透传，还是应该重新建模
所以 ? 用起来很爽，不代表错误边界已经设计正确。
它只是让“传播”更容易，不会替你决定“应该如何表达”。
4.7 错误链和上下文信息很重要
很多复杂问题不是单看错误种类就能定位的，还需要上下文：
- 在处理哪个文件时失败
- 在调用哪个外部接口时失败
- 哪个参数导致了非法状态
所以进阶错误处理通常不只是定义一个 enum，
还要考虑：
- 怎样保留 source error
- 怎样附加上下文
- 怎样让日志足够可排查
也就是说，错误不是单点对象，而是一条“失败信息链”。
4.8 panic 和可恢复错误一定要分清
Rust 很强调这一点：
Result处理可恢复错误panic!处理“不该继续运行”的严重错误或程序员违例
工程里最大的坑之一，就是两边混用：
- 本该返回
Result的地方直接 panic - 本该暴露逻辑 bug 的地方却静默吞错
更成熟的判断是：
- 这是业务上正常可能发生的失败吗 →
Result - 这是违反基本程序假设的错误吗 → panic / assert
4.9 错误处理最终服务的是可维护性
很多人会把错误设计看成“语法洁癖”。
其实它最终影响的是：
- 故障排查速度
- 日志可读性
- API 可理解性
- 系统演进成本
错误处理做得差，系统在成功路径上看起来也许一样；
但一旦失败，维护成本会急剧上升。
5. 常见误区
5.1 误区一：能用 ? 传上去就说明设计没问题
不对。
传播很顺，不代表边界表达合理。
5.2 误区二：所有错误都该保留最底层原貌
不一定。
边界层通常应该做适度抽象，而不是让外部理解全部底层细节。
5.3 误区三：错误信息越详细，越适合直接暴露给用户
错误。
详细不等于合适。很多诊断细节只适合内部日志，不适合外部接口。
5.4 误区四：panic 和错误返回只是风格选择
不是。
它们表达的是两类完全不同的问题：不可恢复违例 vs 可恢复失败。
6. 一个更实用的判断思路
当你设计 Rust 错误类型时，可以先问：
- 这层模块对外究竟要承诺哪些失败类别
- 哪些底层细节应该保留，哪些应该被封装
- 调用方是否需要按错误类别做分支处理
- 当前错误信息是给用户看、给调用方看，还是给开发者排查看
- 这里属于可恢复失败，还是程序假设已被破坏
如果这几个问题想明白，错误类型通常就不会设计得太乱。
7. 学习建议
建议按这个顺序学习错误处理进阶：
- 先彻底理解
Result、Option、?的基本机制 - 再学习为模块设计自己的错误类型
- 再理解错误传播、转换、封装和上下文附加
- 再区分内部诊断信息与外部暴露语义
- 最后再进入更完整的 Web / 服务端错误映射设计
这样会从“会返回错误”过渡到“会设计失败边界”。
8. 自测标准
- 能解释为什么
Result<T, E>里的E设计比容器本身更关键 - 能理解错误类型其实是在定义模块边界
- 能区分“内部细节错误”和“对外暴露错误语义”
- 能知道
?只是在传播错误，不会自动帮你设计错误边界 - 能区分可恢复错误和 panic 级错误
- 能意识到错误处理最终影响的是系统可维护性，而不只是语法风格