为什么错误返回在工程实践中要优于异常捕获Rust、Go、Zig 等新兴语言则回归传统，沿用 C 语言的错误返回方式。在这

为什么错误返回在工程实践中要优于异常捕获

在主流编程语言中，错误处理主要分为两大流派：C++、Java、Python 为代表的面向对象语言，普遍采用 try-catch 异常捕获机制；而 Rust、Go、Zig 等新兴语言则回归传统，沿用 C 语言的错误返回方式。在这篇文章中，我将会浅谈 Rust 的错误处理，并说明为什么错误返回在工程实践中要优于异常捕获。

异常捕获的痛点

不可否认，异常捕获极大的简化了错误处理，在 try 代码块中我们只需要编写正确逻辑的代码，而在 catch 代码块中我们处理异常逻辑，然而这份“简单”是有代价的。

痛点一：隐式控制流，降低代码可维护性

异常捕获的核心问题的是隐式控制流跳转：当函数内部抛出异常时，程序会立即终止当前代码块的执行，回溯调用栈，寻找最近的 try-catch 语句；若未找到匹配的捕获逻辑，程序便会直接崩溃。

这种跳转是隐式的，不同于 if-else、match 等显式分支，开发者在阅读代码时，无法快速判断出哪里会抛出异常、抛出异常后会跳转到哪里。同时，这也让调试变得困难，异常回溯的链路可能跨越多个函数，定位问题根源往往需要耗费大量时间，严重影响代码的可读性与可维护性。

痛点二：栈展开带来的运行时开销

以 Java 为例，当抛出异常时，JVM 会执行“栈展开”操作：从当前方法开始，沿着调用栈一层一层地回溯，寻找能够处理该异常的 catch 代码块。这一过程需要消耗大量的 CPU 资源和时间，若程序频繁抛出异常，会导致运行时性能显著下降。

更关键的是，栈展开的开销是隐性且不可控的，开发者无法提前预判异常抛出的频率，也难以优化栈展开的执行效率，这在高性能场景中尤为致命。

痛点三：资源泄漏风险

异常使用不当极易引发内存泄漏或资源未释放问题。当异常抛出时，若代码中未妥善处理文件句柄、数据库连接、网络连接等资源，就会导致资源长期占用，最终引发系统故障。

以 Java 代码为例，若业务逻辑中抛出异常，资源释放语句将无法执行：

public void example() throws Exception {
    TestResource res = new TestResource();
    res.read();
    // 执行业务逻辑时抛出异常，res.close() 无法执行
    res.close();
}

为解决这一问题，各语言不得不引入额外的语法机制，如 Java 的 try-with-resources、Python 的 with 语句、C# 的 using 语句，这些机制虽然能规避资源泄漏，但同时也增加了样板代码，违背了异常捕获简化编码的初衷。

错误返回：将隐式风险显式化

Rust、Go 等新兴语言放弃异常捕获，选择错误返回，核心逻辑是将隐式风险显式化，也就是让错误成为函数返回值的一部分，强制开发者在编译期处理所有可能的错误，从根源上规避隐式跳转、性能开销和资源泄漏问题。

但显式错误返回也存在天然缺陷，那就是容易产生大量的样板代码，Go 就是非常典型的例子：

if err != nil {
    return err
}

而 Rust 借鉴 Haskell 的设计思想，通过 Option、Result 类型和语法糖，平衡了显式性与简洁性。

Option 与 Result：编译期的错误防护

Rust 提供两种核心类型处理空值和错误，从编译期消除不确定性。Rust 通过 Option<T> 来处理可能为空的场景，它包含两个变体：Some(T)（存在有效值）和 None（空值），定义如下：

pub enum Option<T> {
    None,
    Some(T),
}

编译器会强制开发者处理 None 场景，彻底杜绝了 Java、Python 中常见的空指针异常，将空值风险提前至编译期解决。

Rust 通过 Result<T, E> 处理可能出错的场景，是 Rust 错误返回的核心类型，它包含两个变体：Ok(T)（执行成功，返回有效数据）和 Err(E)（执行失败，返回错误信息）。

下面是一个简单的文件读取示例，通过 Result 显式返回错误：

use std::fs::File;
use std::io::Read;

fn read_file(name: &str) -> Result<String, std::io::Error> {
    let mut f = match File::open(name) {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut contents = String::new();

    match f.read_to_string(&mut contents) {
        Ok(_) => Ok(contents),
        Err(e) => Err(e),
    }
}

通过这个示例可以看出错误返回不可避免地存在着样板代码的问题，但 Rust 通过语法糖解决了这个问题。

语法糖：`?` 操作符

为解决显式错误返回的样板代码问题，Rust 引入 ? 操作符。当调用返回 Result 或 Option 的函数时，? 会自动处理错误：若为 Err 或 None，则立即返回该错误；若为 Ok 或 Some，则提取内部值继续执行。

使用 ? 优化后的文件读取代码，也变得更加简洁，新示例如下所示：

use std::fs::File;
use std::io::Read;

fn read_file(name: &str) -> Result<String, std::io::Error> {
    let mut f = File::open(name)?;
    let mut contents = String::new();
    f.read_to_string(&mut contents)?;
    Ok(contents)
}

`panic!` 与 `catch_unwind`：不可恢复错误的处理

Rust 并非完全摒弃“异常式”的错误处理，而是将其限定在不可恢复错误场景，比如除以零、栈溢出、数组访问越界等严重到影响程序运行的错误，此时触发 panic 是合理的选择。

Rust 提供 panic! 宏主动触发恐慌：执行后，程序会打印错误信息、展开调用栈，最终退出。例如：

fn main() {
    panic!("程序遇到不可恢复错误，终止运行");
}

如果需要像 try-catch 那样捕获恐慌、恢复程序执行，Rust 标准库提供 catch_unwind 函数，可将调用栈回溯至捕获点，实现可恢复的恐慌处理：

use std::panic;

fn main() {
    // 捕获无恐慌的执行
    let result = panic::catch_unwind(|| println!("执行正常"));
    assert!(result.is_ok());

    // 捕获恐慌并处理
    let result = panic::catch_unwind(|| panic!("触发恐慌"));
    assert!(result.is_err());
    println!("捕获到恐慌: {:#?}", result);
}

thiserror 与 anyhow：简化错误处理

在实际工程开发中，手动实现 Rust 标准库的 Error trait 会产生大量重复的样板代码，拉高了错误处理的编码成本。对此，Rust 社区形成了两个被广泛使用的主流解决方案：thiserror 与 anyhow。

二者有着清晰的定位分工：thiserror 专注于简化自定义错误类型的定义，anyhow 则聚焦于通用场景下的错误传播与类型转换，二者搭配使用，能在保留显式错误处理优势的同时，大幅精简样板代码。关于两个库的详细用法、适用场景与最佳实践，我会在后续的文章中单独展开说明。

总结

异常捕获的“简单”，本质是将错误处理的复杂度隐藏在运行时，以隐式跳转、性能开销和资源泄漏为代价；而错误返回的“复杂”，则是将隐式风险显式化，把运行时的不确定性提前至编译期解决。

在 AI Coding 日益普及的今天，显式化的错误处理更易被编译器和 AI 工具识别、分析，能进一步提升开发效率和代码可靠性。这也是为什么，错误返回正在成为现代编程语言的主流选择。它或许增加了少量编码成本，但换来的是代码的可维护性、性能和安全性的全面提升，这正是工程实践中最核心的价值追求。

为什么错误返回在工程实践中要优于异常捕获