Rust 錯誤哲學

---

簡介

在任何程式語言中，錯誤處理都是軟體品質的關鍵。如果錯誤被忽略或處理不當，程式很容易在生產環境中崩潰、產生資料遺失或安全漏洞。Rust 之所以在系統程式領域受到熱烈歡迎，很大程度上來自於它對錯誤處理的嚴謹設計與哲學：

1. 區分可恢復錯誤與不可恢復錯誤，讓開發者在編譯期就能看見錯誤的性質。
2. 以型別系統取代例外機制，避免隱蔽的控制流跳躍，提升程式的可預測性。
3. 鼓勵使用 Result、Option 以及 panic!，讓錯誤的處理方式變得顯式且一致。

本篇文章將深入探討 Rust 的錯誤哲學，說明背後的概念、提供實作範例，並說明在真實專案中如何運用這套機制，幫助你寫出更安全、更可靠的程式碼。

---

核心概念

1. 可恢復錯誤 vs. 不可恢復錯誤

• 可恢復錯誤（Recoverable errors）

  • 代表程式可以在遇到問題後繼續執行，例如檔案不存在、網路請求失敗等。
  • Rust 使用 Result<T, E> 來傳遞此類錯誤，呼叫端必須顯式處理或傳遞。

• 不可恢復錯誤（Unrecoverable errors）

  • 表示程式已進入不可挽回的狀態，通常是程式邏輯錯誤或資源嚴重損毀。
  • Rust 透過 panic! 立即終止執行，並在 debug 時提供回溯資訊。

重點：在設計 API 時，先問自己「這個錯誤是否有可能被呼叫端合理處理？」如果答案是「是」，就回傳 Result；如果「否」，則使用 panic!（或 unwrap/expect 在測試/快速原型中）。

2. Result<T, E> 的結構

enum Result<T, E> {
    Ok(T),      // 成功，攜帶結果值
    Err(E),    // 失敗，攜帶錯誤資訊
}

• T 為成功時的型別，E 為錯誤型別。
• 常見的錯誤型別是 std::io::Error、std::num::ParseIntError，或自行定義的 enum。

3. Option<T> 與錯誤的關係

Option<T> 用於**「值可能不存在」**的情況，與錯誤概念相近但不等同。

• Some(v) 表示有值。
• None 表示「沒有值」——這不一定是錯誤，只是缺失的情況。

在需要區分「缺值」與「錯誤」時，通常會把 Option<T> 包在 Result<T, E> 中，例如 Result<Option<T>, E>。

4. ? 運算子：錯誤傳遞的糖衣

? 讓錯誤的向上傳遞變得簡潔：

use std::fs::File;
use std::io::{self, Read};

fn read_file(path: &str) -> io::Result<String> {
    let mut s = String::new();
    // 若 open 失敗，直接返回 Err，否則取得 File
    let mut f = File::open(path)?;       
    f.read_to_string(&mut s)?;           // 同上
    Ok(s)
}

• ? 只對返回型別為 Result<_, E>（或 Option<_>）的函式有效。
• 若呼叫的結果是 Err(e)，? 會自動 return Err(e.into())。

---

程式碼範例

範例 1：自訂錯誤型別與 Result

use std::fmt;

// 1️⃣ 定義錯誤列舉，實作 std::error::Error
#[derive(Debug)]
enum ConfigError {
    NotFound,
    ParseError(String),
}

// 為了讓錯誤列印更友善，實作 Display
impl fmt::Display for ConfigError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            ConfigError::NotFound => write!(f, "設定檔找不到"),
            ConfigError::ParseError(e) => write!(f, "設定檔解析失敗: {}", e),
        }
    }
}

// 2️⃣ 讓 ConfigError 符合 std::error::Error
impl std::error::Error for ConfigError {}

/// 讀取並解析簡易的設定檔，回傳 Result
fn load_config(path: &str) -> Result<String, ConfigError> {
    // 若檔案不存在，回傳自訂錯誤
    if !std::path::Path::new(path).exists() {
        return Err(ConfigError::NotFound);
    }

    // 假設檔案內容是單行文字，若讀取失敗則轉成自訂錯誤
    let content = std::fs::read_to_string(path)
        .map_err(|e| ConfigError::ParseError(e.to_string()))?;

    Ok(content)
}

說明：

• 透過 enum ConfigError 把不同失敗情境分類，呼叫端可以根據錯誤類型做不同的處理。
• map_err 把 std::io::Error 轉換成我們自己的錯誤型別，保持 API 的一致性。

---

範例 2：使用 Option 搭配 Result 處理「找不到」與「讀取失敗」

use std::fs;

/// 嘗試從環境變數取得檔案路徑，若不存在回傳 None
fn get_path_from_env() -> Option<String> {
    std::env::var("CONFIG_PATH").ok()
}

/// 讀取檔案，回傳 Result<Option<String>, std::io::Error>
/// - Ok(Some(content))   => 成功讀到內容  
/// - Ok(None)            => 環境變數未設定，視為「缺值」  
/// - Err(e)              => 讀檔時發生錯誤
fn load_optional_config() -> Result<Option<String>, std::io::Error> {
    let path = match get_path_from_env() {
        Some(p) => p,
        None => return Ok(None), // 沒設定路徑，直接回傳 None
    };

    let data = fs::read_to_string(path)?;
    Ok(Some(data))
}

說明：

• Option 用於「值可能不存在」的情況（環境變數未設定）。
• Result 用於「可能失敗」的 I/O 操作。兩者結合提供完整的語意。

---

範例 3：? 與 try 區塊（Rust 1.65+）的結合

use std::net::TcpStream;
use std::io::{self, Write};

fn send_message(addr: &str, msg: &str) -> io::Result<()> {
    // try { … } 允許在同一個區塊內使用多個 ?，最後自動回傳 Result
    try {
        let mut stream = TcpStream::connect(addr)?;
        stream.write_all(msg.as_bytes())?;
        // 若需要回傳自訂值，可在區塊結尾寫 `Ok(value)`
        Ok(())
    }
}

說明：try 區塊是語法糖，讓多個 ? 的錯誤傳遞更直觀，等同於手寫 match 或 ? 逐層傳遞。

---

範例 4：panic! 與自訂錯誤訊息

fn divide(a: f64, b: f64) -> f64 {
    if b == 0.0 {
        // 不可恢復錯誤：除以零是程式邏輯錯誤
        panic!("除數不能為零！a = {}, b = {}", a, b);
    }
    a / b
}

說明：

• panic! 會立即中止執行，適合在不可能發生或程式錯誤的情況下使用。
• 在測試或原型階段，unwrap、expect 其實是 panic! 的簡寫。

---

範例 5：錯誤鏈結（Error Chaining）

use std::io;
use thiserror::Error; // 需要加入 thiserror crate

#[derive(Error, Debug)]
enum AppError {
    #[error("I/O 錯誤: {0}")]
    Io(#[from] io::Error),

    #[error("設定解析失敗: {0}")]
    ConfigParse(String),
}

// 讀取檔案並解析，錯誤自動向上鏈結
fn load_and_parse(path: &str) -> Result<String, AppError> {
    let raw = std::fs::read_to_string(path)?; // Io 錯誤自動轉成 AppError::Io
    if raw.trim().is_empty() {
        return Err(AppError::ConfigParse("內容為空".into()));
    }
    Ok(raw)
}

說明：

• thiserror 提供 #[from] 屬性，自動把底層錯誤轉換成上層錯誤，讓錯誤鏈結變得簡潔。

---

常見陷阱與最佳實踐

陷阱	說明	解決方式
過度使用 unwrap / expect	在正式程式碼中直接 panic，會讓錯誤在生產環境中直接崩潰。	只在測試、快速原型或確定不會失敗的情況下使用。正式程式碼改用 ? 或明確的錯誤處理。
把所有錯誤都包成 Box<dyn Error>	雖然可以快速解決型別不匹配，但失去錯誤分類的好處，難以根據錯誤類型做精細處理。	盡量使用具體的錯誤型別或自訂 enum，必要時再用 Box<dyn Error> 作為通用層。
忽略 Result 的返回值	編譯器不會警告未使用的 Result，導致錯誤被悄悄吞掉。	使用 let _ = foo()?; 或 if let Err(e) = foo() { … }，或在 lint 中啟用 unused_must_use。
在 Result 中混用 Option	把 None 當成錯誤處理，會讓呼叫端無法分辨「缺值」與「錯誤」的差別。	明確使用 Result<Option<T>, E>，或在 API 設計時決定哪一層語意更合適。
在 panic! 之後仍寫程式碼	panic! 會立刻 unwind，後面的程式碼永遠不會被執行，可能造成誤解。	把 panic! 放在最後，或直接使用 return Err(...)。

最佳實踐

1. 先思考錯誤是否可恢復：若是，回傳 Result；若不是，使用 panic!（或在測試中使用 unwrap）。
2. 利用 ? 簡化錯誤傳遞，保持程式碼線性。
3. 自訂錯誤型別，讓錯誤資訊更具可讀性與可擴充性。
4. 在公共 API 中避免暴露底層錯誤，使用抽象的錯誤層（例如 AppError），同時保留 source() 供除錯。
5. 啟用 Lint：cargo clippy、rustc -D warnings，確保未處理的 Result 會被警告。

---

實際應用場景

1. CLI 工具的參數解析

CLI 程式常需要處理使用者輸入錯誤、檔案不存在、權限不足等情況。典型做法是：

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let args: Vec<String> = std::env::args().collect();
    let path = args.get(1).ok_or("請提供檔案路徑")?;
    let content = std::fs::read_to_string(path)?;
    println!("檔案內容:\n{}", content);
    Ok(())
}

• 透過 Result<(), Box<dyn Error>> 把所有錯誤聚合，main 只需要 ?，最終由 runtime 顯示錯誤訊息。

2. 網路服務的請求處理

在 actix-web、warp 等框架中，錯誤往往需要轉換成 HTTP 回應：

use actix_web::{get, HttpResponse, Responder};

#[derive(thiserror::Error, Debug)]
enum ApiError {
    #[error("資料庫錯誤")]
    Db(#[from] sqlx::Error),

    #[error("找不到資源")]
    NotFound,
}

impl actix_web::ResponseError for ApiError {
    fn error_response(&self) -> HttpResponse {
        match self {
            ApiError::Db(_) => HttpResponse::InternalServerError().finish(),
            ApiError::NotFound => HttpResponse::NotFound().finish(),
        }
    }
}

#[get("/user/{id}")]
async fn get_user(path: actix_web::web::Path<u32>) -> Result<impl Responder, ApiError> {
    let id = path.into_inner();
    let user = sqlx::query_as::<_, User>("SELECT * FROM users WHERE id = $1")
        .bind(id)
        .fetch_one(&POOL)
        .await?;
    Ok(HttpResponse::Ok().json(user))
}

• ApiError 把底層錯誤抽象化，ResponseError 讓框架自動把錯誤映射成 HTTP 狀態碼。

3. 嵌入式開發中的資源限制

在資源受限的嵌入式環境，不可恢復錯誤往往意味著系統必須安全關機。此時會使用 panic! 並在 panic hook 中執行清理：

fn main() -> ! {
    std::panic::set_hook(Box::new(|info| {
        // 寫入 UART、關閉外設等
        log::error!("系統發生不可恢復錯誤: {}", info);
        // 進入安全關機
        unsafe { cortex_m::asm::bkpt(); }
    }));

    // 正常執行
    if let Err(e) = init_peripherals() {
        panic!("外設初始化失敗: {}", e);
    }

    loop {
        // 主循環...
    }
}

• 只在真的無法繼續執行的情況下使用 panic!，並在 hook 中確保硬體安全。

---

總結

Rust 的錯誤哲學核心在於 「讓錯誤變得可見、可控制」。透過 Result、Option、panic! 三大工具，配合型別系統與 ? 語法糖，開發者可以在編譯期就捕捉到大多數潛在問題，並在執行期以一致且可預測的方式處理錯誤。

• 可恢復錯誤：使用 Result<T, E>，明確傳遞錯誤資訊。
• 不可恢復錯誤：使用 panic! 或在測試中使用 unwrap。
• 錯誤鏈結：thiserror、anyhow 等 crate 能讓錯誤資訊更豐富，方便除錯。
• 最佳實踐：自訂錯誤型別、避免過度 unwrap、啟用 lint、在 API 設計時明確區分 Option 與 Result。

掌握這套哲學後，你的 Rust 程式不僅在 安全性、可維護性 上大幅提升，也能在 效能 與 開發速度 之間取得良好平衡。未來無論是 CLI、Web 服務、或是嵌入式系統，都能以相同的錯誤處理模式，寫出一致且可靠的程式碼。祝你在 Rust 的旅程中，錯誤不再是阻礙，而是成長的養分！