编程语言中的错误处理模型
错误处理的本质，不是“程序报错了怎么办”，而是系统在出现异常情况时，如何决定继续运行、终止运行、释放资源，以及把问题传递给谁。
不同语言在语法和机制上差异很大，但它们最终都在回答同几类问题：
- 什么算错误，什么算 bug
- 哪些错误可以恢复，哪些错误必须终止
- 错误应该如何向上层传播
- 资源应该在什么时机释放
- 异步流程中的错误还能不能沿着原来的调用链处理
错误不止一种
从工程视角看，错误通常至少可以分成两类：
- 可恢复错误：操作失败了，但程序仍然可以决定如何处理，例如文件不存在、网络超时、参数格式不合法
- 不可恢复错误：程序已经进入不可信状态，继续运行可能造成更严重的问题，例如数组越界、空指针解引用、违反内部不变量
不同语言对这两类错误的表达方式不同。
- Rust 倾向于把可恢复错误显式放进
Result<T, E>，把不可恢复错误交给panic! - Java、Python、JavaScript 更常见的是异常模型，通过
throw/try-catch一路传播
这背后的分歧并不是语法风格，而是设计哲学：错误究竟应该被当成普通控制流的一部分，还是被当成打断控制流的异常事件。
返回值模型 vs 异常模型
错误处理大致可以抽象成两条路线。
返回值模型
返回值模型把“成功”与“失败”都编码进函数返回值里，例如：
- 成功时返回结果
- 失败时返回错误对象或错误分支
Rust 的 Result<T, E> 是最典型的代表。这种模型的优点是：
- 错误路径显式，调用者很难假装没看到
- 错误类型可以参与类型系统约束
- 控制流相对可预测
代价也很明显：
- 代码更容易显得啰嗦
- 错误传播如果没有语法糖会非常吵
异常模型
异常模型把错误从普通返回值里分离出来，函数在失败时直接抛出异常，由上层选择捕获。
Java、Python、JavaScript 都主要依赖这条路线。它的优点是：
- 业务路径可以写得更干净
- 多层调用中，错误传播不必层层手动返回
代价在于：
- 错误路径更隐式
- 如果边界设计不好，异常可能传播过远
- 开发者更容易“先抛再说”，最后失去错误语义分层
错误传播的核心问题
错误处理并不只是“捕获”。更关键的问题是：谁应该处理这个错误？
一般来说：
- 离错误最近的代码，最了解错误发生的上下文
- 但离用户最近的代码，才最有资格决定最终如何呈现或终止
所以很多系统的最佳实践不是“哪里出错哪里吞掉”，而是：
- 在底层保留足够上下文
- 在中间层适当转换错误语义
- 在边界层决定记录日志、重试、降级还是终止
如果每一层都立即处理并吞掉错误，最后系统只会留下模糊的“失败了”；如果每一层都只会继续向上抛，最后又会失去上下文和业务判断。
内存清理和资源释放
错误处理一定会牵涉到资源释放，因为程序出错时，文件句柄、锁、网络连接、事务、临时内存并不会自动“理解你的业务意图”。
不同语言对资源清理的处理方式也不同：
- Rust 依赖作用域和
Drop，资源在离开作用域时自动回收 - Java、Python、JavaScript 更依赖
finally、defer风格结构或上下文管理器来保证清理逻辑一定执行
这说明错误处理从来都不是单纯的控制流问题，它还直接影响资源安全。
一个成熟的错误处理模型，必须回答这个问题：如果中途失败了，已经拿到的资源由谁负责善后？
错误传播与代码简洁
错误处理还有一个长期冲突：显式通常更安全，但也更吵；简洁通常更易读，但也更容易隐藏路径。
这也是为什么不同语言都在寻找某种平衡：
- Rust 用
?来压缩Result的传播噪音 - Java 用异常机制减少层层返回值判断
- Python 倾向于让异常自然冒泡，再在合适边界集中处理
- JavaScript 在同步场景中用
try...catch，在异步场景中又引入Promise.catch()和async/await
所以真正好的错误处理代码，不是“看起来很高级”，而是：
- 正常路径清晰
- 错误路径可追踪
- 资源释放有保证
- 调用边界职责明确
异步错误处理为什么更麻烦
同步代码里，错误通常沿着调用栈向上传播；而异步代码会打断原本的调用链，因此错误处理会变得更复杂。
典型问题包括：
- 错误发生时，原来的调用者可能早就返回了
try...catch不一定能捕获另一个事件循环 tick 中抛出的错误- 错误可能包在 Future、Promise、Task 这样的抽象里传播
- 一部分错误发生在任务取消、超时、并发竞争之后，已经不是简单的“抛异常”能概括的了
所以异步错误处理通常需要额外关注：
- 错误是否真的被观察到了
- 任务失败后是否会静默丢失
- 超时、取消、重试是否属于同一类错误
异步系统里最危险的往往不是“报错”，而是“悄悄失败”。
各语言的典型取舍
| 语言 | 主要模型 | 典型特点 |
|---|---|---|
| Rust | 返回值模型 | 用 Result 区分可恢复错误，用 panic! 表示不可恢复错误，强调显式处理 |
| JavaScript | 异常模型 | 同步错误和异步错误处理方式差异很大，Promise 和事件循环会改变传播路径 |
| Python | 异常模型 | 语法简洁，适合集中捕获，但过度宽泛地捕获异常会掩盖真实问题 |
| Java | 异常模型 | 强调异常层级和类型系统约束，checked / unchecked exception 是重要分界 |
没有一种模型能在所有场景里完全胜出。
- 返回值模型更强调可预测性
- 异常模型更强调表达力和代码简洁
- 自动资源管理能减轻清理负担，但不会替你做业务决策
- 异步支持提升并发能力，也会让错误路径更绕
错误处理的常见误区
- 以为错误处理就是
try...catch - 以为所有错误都应该立即在本层解决
- 以为“捕获所有异常”是一种稳妥做法
- 以为记录日志就等于处理完错误
- 以为异步代码里的错误会像同步代码那样自然冒泡
- 以为资源释放和错误处理是两回事
这些误区的共同问题是：只看到了“报错”这个动作，没有看到错误处理背后的系统边界、资源生命周期和控制流设计。
如何判断一段错误处理写得好不好
可以用几个问题快速检查：
- 这个错误是可恢复还是不可恢复？
- 这一层真的有足够信息处理它吗？
- 如果继续向上传播，是否会丢失上下文？
- 出错后资源是否会被正确释放？
- 异步场景下，这个错误是否一定会被观察到？
- 最后拿到这个错误的人，能不能据此做出正确决策？
如果这些问题都答得清楚，这段错误处理大概率就是靠谱的。