错误处理哲学：Rust为何没有异常？Result与Option的设计理念

说实话，我第一次接触Rust时，最让我困惑的就是它竟然没有异常机制。

我当时想：一个现代语言，连try-catch都没有，这怎么用？

但用了半年后，我彻底服了。Rust不是做不了异常，而是选择了另一条路——一条更安全、更显式的路。

为什么Rust抛弃了异常？

先聊聊异常的本质。你想想看，异常其实是一种隐式的控制流。函数正常返回是一种路径，抛出异常是另一种路径。这两种路径在代码里看起来完全不同，但运行时却可能交织在一起。

我在项目中遇到过这样的场景：一个Java服务，某个底层函数抛了个空指针异常，结果上层catch块没处理好，整个线程挂了。排查了整整两天，才发现是某个边界条件触发的。

Rust团队认为，异常机制有两个核心问题：

• 不可见性：调用者不知道函数会不会抛异常，除非看文档或源码
• 不可控性：异常可以在调用栈中任意传播，你很难确定它最终在哪里被捕获

说白了，异常把错误处理的责任从编译时推到了运行时。而Rust的理念是：能在编译期解决的问题，绝不拖到运行时。

Result：显式的错误处理

Rust用Result<T, E>来替代异常。它的定义很简单：

enum Result<T, E> {
    Ok(T),
    Err(E),
}

每个可能失败的函数，返回值里都明确写着：我可能成功，也可能失败。调用者必须处理这两种情况，否则代码编译不过。

举个例子，读取文件：

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

fn read_config() -> Result<String, std::io::Error> {
    let mut file = File::open("config.toml")?;
    let mut content = String::new();
    file.read_to_string(&mut content)?;
    Ok(content)
}

注意那个?操作符。它是个语法糖，等价于：

let mut file = match File::open("config.toml") {
    Ok(f) => f,
    Err(e) => return Err(e),
};

我个人习惯用?操作符，它让代码干净很多。但要注意，?只能在返回Result或Option的函数里用。

Option：可能为空的值

空指针是无数bug的根源。Tony Hoare（空引用的发明者）后来都公开道歉，称这是他的"十亿美元错误"。

Rust用Option<T>来解决这个问题：

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

任何可能为空的值，都必须用Option包裹。你想用里面的值？必须先解包。这就杜绝了空指针访问。

我举个例子，从HashMap里取值：

use std::collections::HashMap;

let mut scores = HashMap::new();
scores.insert("Alice", 100);

// 返回值是 Option<&i32>
let score = scores.get("Bob");

// 必须处理 None 的情况
match score {
    Some(v) => println!("Bob's score: {}", v),
    None => println!("Bob not found"),
}

我曾经在C++项目里被空指针坑过无数次。一个指针传了五层函数，突然在某处解引用时崩了。用Rust后，这种问题再也没出现过。

错误处理的核心流程

下面这张图展示了Rust错误处理的完整流程：

这张图的核心逻辑是：每个可能失败的函数，返回值都明确标注了错误类型。调用者必须显式处理成功和失败两种情况。

实战中的错误处理策略

我总结了几条实战经验，分享给你：

1. 用自定义错误类型：不要到处用String当错误。定义自己的Error枚举，实现std::error::Error trait。
2. 善用thiserror和anyhow：thiserror适合库项目，anyhow适合应用项目。这两个crate能省很多样板代码。
3. 不要滥用unwrap()：unwrap()在原型阶段可以用，但生产代码里尽量用expect()，至少能提供错误上下文。

错误类型的传播与转换

实际项目中，错误类型往往需要转换。比如你的函数调用了多个库，每个库的错误类型不同：

use std::io;
use serde_json;

#[derive(Debug)]
enum MyError {
    Io(io::Error),
    Json(serde_json::Error),
}

impl From<io::Error> for MyError {
    fn from(e: io::Error) -> Self {
        MyError::Io(e)
    }
}

impl From<serde_json::Error> for MyError {
    fn from(e: serde_json::Error) -> Self {
        MyError::Json(e)
    }
}

fn read_and_parse(path: &str) -> Result<serde_json::Value, MyError> {
    let content = std::fs::read_to_string(path)?;  // io::Error 自动转为 MyError
    let data: serde_json::Value = serde_json::from_str(&content)?;  // serde_json::Error 自动转为 MyError
    Ok(data)
}

这里的关键是From trait。只要实现了From，?操作符就能自动做类型转换。这个设计非常优雅，我特别喜欢。

Option与Result的互转

有时候我们需要在Option和Result之间转换：

// Option 转 Result
let opt: Option<i32> = Some(42);
let res: Result<i32, &str> = opt.ok_or("value is None");

// Result 转 Option
let res: Result<i32, &str> = Ok(42);
let opt: Option<i32> = res.ok();

我个人习惯在需要提供错误上下文时用ok_or，否则直接用Option更简洁。

总结一下

Rust的错误处理哲学，说白了就是一句话：把错误当作值来处理。

异常是隐式的、不可控的。而Result和Option是显式的、可控的。它们把错误处理从运行时拉到了编译期，让编译器帮你检查是否遗漏了错误路径。

刚开始可能会觉得麻烦，但习惯了之后，你会发现这种设计带来的安全感是无可替代的。

---