面试题：Rust panic!宏与错误处理机制的协同调试

Question

在Rust项目中，既有通过Result和Option进行常规错误处理，又使用了panic!宏。请说明在复杂业务逻辑下，如何协调二者进行高效调试，例如在哪些情况下应优先使用panic!宏中断程序，哪些情况下应使用Result进行错误传播并持续运行部分逻辑。

Answer 1

1. 使用 panic! 宏的场景

• 不可恢复的错误：当程序遇到无法继续正常运行的情况时，例如配置文件格式严重错误，导致程序无法获取关键的初始化信息，这时使用 panic! 中断程序是合适的。比如在读取数据库连接配置时，如果格式完全错误，无法解析出数据库地址、用户名等关键信息，后续数据库相关操作肯定无法进行，就可以使用 panic!。

let config = std::fs::read_to_string("config.txt").expect("Failed to read config file");
let parts: Vec<&str> = config.split('=').collect();
if parts.len() != 2 {
    panic!("Invalid config format");
}

• 开发和测试阶段：在开发和测试过程中，对于一些临时的断言或用于快速定位逻辑错误的情况，可以使用 panic!。例如，在函数内部对某个预期的状态进行断言，如果不满足则中断程序，方便调试。

fn divide(a: i32, b: i32) -> i32 {
    assert!(b != 0, "Division by zero");
    a / b
}

这里 assert! 宏在发布版本会被移除，而 panic! 可以在开发测试时快速发现问题。

2. 使用 Result 的场景

• 可恢复的错误：当错误发生后，程序的其他部分仍有可能继续执行有用的工作时，应使用 Result。例如在文件系统操作中，读取一个文件可能失败，但程序可以继续处理其他文件。

fn read_file_content(file_path: &str) -> Result<String, std::io::Error> {
    std::fs::read_to_string(file_path)
}
fn process_files() {
    let file_paths = vec!["file1.txt", "file2.txt", "file3.txt"];
    for path in file_paths {
        match read_file_content(path) {
            Ok(content) => println!("Processed {}: {}", path, content),
            Err(e) => eprintln!("Failed to read {}: {}", path, e),
        }
    }
}

• 错误传播：在函数调用链中，如果当前函数无法处理某个错误，但上层调用者可能有能力处理，就应该使用 Result 进行错误传播。例如一个库函数读取网络数据，它不应该中断调用者的整个程序，而是将错误返回给调用者处理。

fn fetch_data(url: &str) -> Result<String, reqwest::Error> {
    reqwest::blocking::get(url)?.text()
}

这里 ? 操作符将错误传播给调用者，调用者可以决定如何处理这个错误，而不是直接中断程序。