改进rust代码的35种具体方法-类型(十八)-不要惊慌

上一篇文章

它看起来非常复杂，这就是为什么它贴合的塑料盖上用大号友好字母印上“不要恐慌”的原因之一。——道格拉斯·亚当斯

此项目的标题将更准确地描述为更喜欢返回Result而不是使用panic!（但不要惊慌更吸引人）。

Rust的panic机制主要是为程序中不可恢复的错误而设计的，默认情况下它会终止发出panic的线程。然而，这个默认值还有其他替代方案。

特别是，来自具有异常系统（如Java或C++）的语言的Rust新手有时会扑向std::panic::catch_unwind作为模拟异常的一种方式，因为它似乎提供了一种在呼叫堆栈更远的点捕获恐慌的机制。

fn divide(a: i64, b: i64) -> i64 {
    if b == 0 {
        panic!("Cowardly refusing to divide by zero!");
    }
    a / b
}

尝试用无效输入调用此内容，按预期失败：

// Attempt to discover what 0/0 is...
let result = divide(0, 0);

thread 'main' panicked at 'Cowardly refusing to divide by zero!', main.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

使用catch_unwind捕捉恐慌的包装器：

fn divide_recover(a: i64, b: i64, default: i64) -> i64 {
    let result = std::panic::catch_unwind(|| divide(a, b));
    match result {
        Ok(x) => x,
        Err(_) => default,
    }
}

似乎工作并模拟catch：

let result = divide_recover(0, 0, 42);
println!("result = {result}");

result = 42

然而，外表可能是欺骗性的。这种方法的第一个问题是，恐慌并不总是解除；有一个编译器选项（也可以通过Cargo.toml配置文件设置访问），可以转移恐慌行为，以便立即中止该过程：

thread 'main' panicked at 'Cowardly refusing to divide by zero!', main.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
/bin/sh: line 1: 29100 Abort trap: 6 cargo run --release

这使得任何模拟异常的尝试完全受制于更广泛的项目设置。同样，一些目标平台（例如WebAssembly）总是在恐慌时中止，无论任何编译器或项目设置如何。

恐慌处理暴露的一个更微妙的问题是异常安全：如果恐慌发生在数据结构操作的中途，它会消除数据结构处于自洽状态的任何保证。众所周知，自20世纪90年代以来，在存在异常的情况下保留内部不变量是非常困难的；1这是谷歌（著名的）禁止在其C++代码中使用异常的主要原因之一。

最后，恐慌传播也与FFI（外部函数接口）边界的相互作用很差；使用catch_unwind防止Rust代码中的恐慌跨越FFI边界传播到非Rust调用代码。

那么，除了恐慌，还有什么办法呢?处理错误条件?对于库代码，最好的替代方法是通过返回带有适当错误类型(Item 4)的Result，使错误成为其他人的问题。这允许库用户自己决定下一步要做什么——这可能涉及将问题传递给行中的下一个调用者，通过?操作符。

责任总有止点，一个有用的经验法则是，恐慌是可以的!(或者unwrap()， expect()等)，如果你控制了main;在这一点上，没有进一步的调用者可以将责任传递给。

又一个明智的恐慌!即使在库代码中，在很少遇到错误的情况下也是如此，并且您不希望用户不得不使用.unwrap()调用来丢弃他们的代码。

如果错误情况只是因为（例如）内部数据损坏，而不是由于无效的输入，那么就会引发panic!是合法的。

允许由无效输入触发的恐慌，但此类无效输入不同寻常，这甚至偶尔也是有用的。当相关切入点成对出现时，这效果最佳：