Rust 的错误处理：别拿类型系统当护身符 - 教程

文章目录

• • 一、错误的核心：调用者到底需要知道什么？
  • • 错误示例：不区分错误来源
    • 正确示例：枚举错误来源
  • 二、错误信息越多不代表更好
  • • 过度设计的灾难
    • 实用设计：擦除无关信息
  • 三、特殊情况是设计的失败
  • • 错误示例：用 Option 偷懒
    • 正确示例：用 Result 明确语义
  • 四、操作符不是魔法，是糖衣
  • • 错误示例：只实现了 Into
    • 正确示例：实现 From，一切通顺
  • 五、try block：清理不该被跳过的东西
  • • 正确做法：try block
  • 六、永远别为“优雅”破坏用户空间

大多数 Rust 程序员在处理错误时表现得像被编译器吓坏了的孩子。
他们害怕 Result、害怕 ?、害怕 lifetimes，最后写出一堆看起来“类型安全”的垃圾。
问题不在语言，而在思维：错误处理是设计问题，不是语法问题。

---

一、错误的核心：调用者到底需要知道什么？

如果调用者需要知道错误的来源，就枚举（enumeration）。
如果调用者只需要知道“出错了”，就擦除（erasure）。

---

错误示例：不区分错误来源

fn copy_data(mut reader: impl Read, mut writer: impl Write) -> Result<(), std::io::Error> {
  std::io::copy(&mut reader, &mut writer)?;
  Ok(())
  }

看起来很简洁对吧？问题是：调用者根本不知道是读挂了还是写炸了。

在网络服务器里，这两个错误是完全不同的：

• 输入流失败可能意味着磁盘或 socket 损坏（致命）
• 输出流失败可能只是客户端断开（可以忽略）

但现在它们都被混在一个 std::io::Error 里，你的调用者只能瞎猜。

---

正确示例：枚举错误来源

#[derive(Debug)]
pub enum CopyError {
In(std::io::Error),
Out(std::io::Error),
}
impl std::error::Error for CopyError {}
impl std::fmt::Display for CopyError {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
  match self {
  CopyError::In(e) => write!(f, "input error: {}", e),
  CopyError::Out(e) => write!(f, "output error: {}", e),
  }
  }
  }
  fn copy_data(mut reader: impl Read, mut writer: impl Write) -> Result<(), CopyError> {
    let mut buf = [0; 4096];
    loop {
    let n = reader.read(&mut buf).map_err(CopyError::In)?;
    if n == 0 { break; }
    writer.write_all(&buf[..n]).map_err(CopyError::Out)?;
    }
    Ok(())
    }

现在调用者能区分错误来源，可以决定不同的策略。
这才叫语义清晰。类型系统不是目标，它是防止你撒谎的手段。

---

二、错误信息越多不代表更好

有的人以为“详细 = 专业”，于是他们搞出这种 monstrosity：

过度设计的灾难

#[derive(Debug)]
enum DecodeError {
InvalidHeader(u32),
UnsupportedCompression(String),
MalformedChunk(usize),
IoError(std::io::Error),
}

然后每个错误都被上报、打印、打 tag。
问题是：上层调用者根本不在意。
他们只想知道“图片读不出来”，不在乎是哪个 bit 出问题。

---

实用设计：擦除无关信息

#[derive(Debug)]
struct ImageError(String);
impl std::fmt::Display for ImageError {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
  write!(f, "image decoding failed: {}", self.0)
  }
  }
  impl std::error::Error for ImageError {}
  fn decode_image(data: &[u8]) -> Result<Image, ImageError> {
    // 内部可以区分多种错误
    let header = parse_header(data).map_err(|_| ImageError("invalid header".into()))?;
    decompress(header).map_err(|_| ImageError("decompression failed".into()))?;
    Ok(Image::new())
    }

用户得到的是干净的 ImageError，无需知道底层细节。
擦除复杂度，不是隐藏错误，而是隔离不必要的信息。

---

三、特殊情况是设计的失败

很多人写函数时遇到“理论上不会失败”的情况，就乱来。

错误示例：用 Option 偷懒

fn parse_number(s: &str) -> Option<i32> {
  s.parse().ok()
  }

看起来简洁，但 None 到底是什么意思？
是字符串不是数字？是空字符串？是 I/O 出错？
调用者完全没法判断——你直接剥夺了他们的恢复能力。

---

正确示例：用 Result 明确语义

#[derive(Debug)]
struct ParseNumberError;
impl std::fmt::Display for ParseNumberError {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
  write!(f, "invalid number format")
  }
  }
  impl std::error::Error for ParseNumberError {}
  fn parse_number(s: &str) -> Result<i32, ParseNumberError> {
    s.parse().map_err(|_| ParseNumberError)
    }

Result 表示“有错误发生”；Option 表示“没有值返回”。
混用这两个类型，是 API 设计的懒惰行为。
如果函数可能失败，就让类型系统告诉调用者这件事。

---

四、操作符不是魔法，是糖衣

有人以为 ? 很神秘，其实它就是：

match expr {
Ok(v) => v,
Err(e) => return Err(e.into()),
}

所以关键不在 ?，而在 From trait。

---

错误示例：只实现了 Into

impl Into<MyError> for std::io::Error {
  fn into(self) -> MyError { MyError::Io(self) }
  }

然后惊讶地发现：? 报错，“trait bound not satisfied”。
因为 ? 调用的是 From::from，不是 Into::into。

---

正确示例：实现 From，一切通顺

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

从此你可以愉快地写：

fn read_file() -> Result<String, MyError> {
  let mut buf = String::new();
  std::fs::File::open("config.txt")?.read_to_string(&mut buf)?;
  Ok(buf)
  }

---

五、try block：清理不该被跳过的东西

很多人喜欢：

fn run() -> Result<(), Error> {
  let conn = connect()?;
  do_stuff(&conn)?;
  conn.close()?; // 这一行永远执行不到
  Ok(())
  }

一旦 do_stuff 出错，close() 永远不会跑到。
Rust 的 ? 让你早退，但不会帮你擦屁股。

---

正确做法：try block

fn run() -> Result<(), Error> {
  let conn = connect()?;
  let r = try {
  do_stuff(&conn)?;
  };
  conn.close()?;
  r
  }

这才是可靠的错误处理：不丢资源，不绕逻辑。
try {} 块让你能在出错时执行 cleanup，而不破坏 ? 的流畅性。

---

六、永远别为“优雅”破坏用户空间

有些库作者干了这种蠢事：

// v1.0
pub fn foo() -> Result<(), Box<dyn Error>>;
  // v1.1
  pub fn foo() -> Result<(), Box<MyError>>;

然后他们说：“签名没变呀！编译器不会报错！”

但用户代码里：

match foo() {
Err(e) => {
if let Some(ioe) = e.downcast_ref::<std::io::Error>() {
  // ...
  }
  }
  }

现在全部崩了。
如果用户能 downcast，那类型擦除就是你的 API 一部分。
别假装不是。
这类破坏兼容性的更改，永远是破坏性更新（breaking change）。

---