它看起来非常复杂，这就是为什么它贴合的塑料盖上用大号友好字母印上"不要恐慌"的原因之一。------道格拉斯·亚当斯
此项目的标题将更准确地描述为更喜欢返回Result而不是使用panic! （但不要惊慌更吸引人）。
Rust的panic机制主要是为程序中不可恢复的错误而设计的，默认情况下它会终止发出panic的线程。然而，这个默认值还有其他替代方案。
特别是，来自具有异常系统（如Java或C++）的语言的Rust新手有时会扑向std::panic::catch_unwind作为模拟异常的一种方式，因为它似乎提供了一种在呼叫堆栈更远的点捕获恐慌的机制。
rust
fn divide(a: i64, b: i64) -> i64 {
if b == 0 {
panic!("Cowardly refusing to divide by zero!");
}
a / b
}尝试用无效输入调用此内容，按预期失败：
rust
// 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捕捉恐慌的包装器：
rust
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：
rust
let result = divide_recover(0, 0, 42);
println!("result = {result}");
rust
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!是合法的。
允许由无效输入触发的恐慌，但此类无效输入不同寻常，这甚至偶尔也是有用的。当相关切入点成对出现时，这效果最佳：
- 一个"无懈可犯"的版本，其签名意味着它总是成功的（如果它不能成功，就会惊慌失措）
- 一个"易失"版本，返回一个
Result
对于前者，Rust的API指南表明panic!应在内联文档的特定部分中记录。
标准库中的String::from_utf8_unchecked和String::from_utf8入口点是后者的一个例子（尽管在这种情况下，恐慌实际上被推迟到使用由无效输入构造的aString）。
假设您试图遵守本项目中的建议，有几件事需要记住。首先，恐慌可以以不同的形式出现；避免panic!还涉及避免以下内容：
更难发现的是以下东西：
slice[index]当指数不在范围之内时x / y当y为零时
关于避免恐慌的第二个观察是，一个涉及人类持续警惕的计划从来都不是一个好主意。
然而，对机器的持续警惕是另一回事：在您的持续集成系统中添加检查，以发现新的、可能恐慌的代码要可靠得多。一个简单的版本可能是最常见的恐慌进入点的简单grep（如前所示）；更彻底的检查可能涉及来自Rust生态系统的额外工具，例如设置一个构建变体来拉入no_panic板条箱。
1 Tom Cargill1994年在C++报告中的文章探讨了C++模板代码的异常安全有多困难，Herb Sutter的本周大师#8专栏也是如此。
下一篇文章-避免使用反射
https://blog.csdn.net/qq_34841911/article/details/139180459