何时应该使用 panic!
那么如何决定何时应该调用 panic!，何时应该返回 Result 呢？当代码 panic 时，就无法恢复了。你可以为任何错误情况调用 panic!，无论是否有可能恢复，但这意味着你替调用代码做出了一个情况不可恢复的决定。当你选择返回 Result 值时，你就给了调用代码选择的机会。调用代码可以选择以适合其情况的方式尝试恢复，或者它可以决定在这种情况下 Err 值是不可恢复的，因此它可以调用 panic! 并将你的可恢复错误转换为不可恢复的错误。因此，当你定义一个可能失败的函数时，返回 Result 是一个很好的默认选择。
在示例、原型代码和测试等情况下，编写 panic 的代码比返回 Result 更合适。让我们探讨一下原因，然后讨论编译器无法判断失败是不可能的，但你作为一个人可以判断的情况。本章最后将给出一些关于如何在库代码中决定是否 panic 的一般性指导原则。
示例、原型代码和测试
当你编写示例来说明某个概念时，如果还包含健壮的错误处理代码，可能会使示例变得不那么清晰。在示例中，可以理解为，对 unwrap 等可能 panic 的方法的调用是为了说明你希望应用程序如何处理错误，这可能会根据代码其余部分的功能而有所不同。
类似地，在原型设计阶段，在你准备好决定如何处理错误之前，unwrap 和 expect 方法非常方便。它们在你的代码中留下了清晰的标记，以便在你准备好使程序更加健壮时使用。
如果一个方法调用在测试中失败了，你希望整个测试都失败，即使该方法不是被测试的功能。因为 panic! 是标记测试失败的方式，所以调用 unwrap 或 expect 正是你应该做的。
你比编译器拥有更多信息的情况
当你有一些其他逻辑可以确保 Result 将具有 Ok 值时，调用 unwrap 或 expect 也是合适的，但编译器无法理解这些逻辑。你仍然会有一个需要处理的 Result 值：无论你调用什么操作，通常都有可能失败，即使在你的特定情况下逻辑上是不可能的。如果你可以通过手动检查代码来确保你永远不会遇到 Err 变体，那么调用 unwrap 是完全可以接受的，甚至更好的是在 expect 文本中记录你认为你永远不会遇到 Err 变体的原因。下面是一个例子
fn main() { use std::net::IpAddr; let home: IpAddr = "127.0.0.1" .parse() .expect("Hardcoded IP address should be valid"); }
我们通过解析一个硬编码的字符串来创建一个 IpAddr 实例。我们可以看到 127.0.0.1 是一个有效的 IP 地址，所以在这里使用 expect 是可以接受的。然而，拥有一个硬编码的有效字符串并不会改变 parse 方法的返回类型：我们仍然会得到一个 Result 值，编译器仍然会让我们像处理 Err 变体一样处理 Result，就好像 Err 变体是可能的一样，因为编译器不够聪明，无法识别这个字符串始终是一个有效的 IP 地址。如果 IP 地址字符串来自用户而不是硬编码到程序中，因此确实有可能失败，那么我们肯定希望以更健壮的方式处理 Result。提到这个 IP 地址是硬编码的假设将促使我们改变 expect 为更好的错误处理代码，如果在将来我们需要从其他来源获取 IP 地址的话。
错误处理指南
当你的代码有可能处于错误状态时，建议让它 panic。在这种情况下，*错误状态*是指某些假设、保证、约定或不变量被破坏，例如将无效值、矛盾值或缺失值传递给你的代码，以及以下一种或多种情况：
- 错误状态是意外发生的，而不是像用户输入错误格式的数据那样偶尔发生。
- 此后你的代码需要依赖于不处于这种错误状态，而不是在每一步都检查问题。
- 没有很好的方法在你使用的类型中编码此信息。我们将在第 17 章的“将状态和行为编码为类型”部分中通过一个示例来说明我们的意思。。
如果有人调用你的代码并传入无意义的值，最好是尽可能返回一个错误，以便库的用户可以决定在这种情况下他们想要做什么。但是，在继续运行可能不安全或有害的情况下，最好的选择可能是调用 panic! 并提醒使用你的库的人注意其代码中的错误，以便他们在开发过程中修复它。类似地，如果你正在调用超出你控制范围的外部代码，并且它返回了你无法修复的无效状态，那么 panic! 通常是合适的。
但是，当预期会失败时，返回 Result 比进行 panic! 调用更合适。例如，解析器被赋予格式错误的数据，或者 HTTP 请求返回指示你已达到速率限制的状态。在这些情况下，返回 Result 表示失败是一种预期的可能性，调用代码必须决定如何处理。
当你的代码执行的操作在使用无效值调用时可能会使用户面临风险时，你的代码应首先验证值是否有效，如果值无效则 panic。这主要是出于安全原因：尝试对无效数据进行操作可能会使你的代码暴露于漏洞。这是标准库在你尝试进行越界内存访问时会调用 panic! 的主要原因：尝试访问不属于当前数据结构的内存是一个常见的安全问题。函数通常有*约定*：只有在输入满足特定要求时才能保证其行为。当违反约定 panic 是有意义的，因为违反约定始终表示调用方存在错误，并且这不是你希望调用代码必须显式处理的错误类型。实际上，调用代码没有合理的方法可以恢复；调用*程序员*需要修复代码。函数的约定，尤其是当违反约定会导致 panic 时，应在函数的 API 文档中进行说明。
但是，在所有函数中进行大量错误检查将非常冗长且烦人。幸运的是，你可以使用 Rust 的类型系统（以及编译器执行的类型检查）来为你完成许多检查。如果你的函数将特定类型作为参数，你可以继续执行代码的逻辑，因为你知道编译器已经确保你拥有有效值。例如，如果你有一个类型而不是 Option，则你的程序希望有*某些东西*而不是*什么都没有*。然后，你的代码不必处理 Some 和 None 变体的两种情况：它只有一种情况肯定有一个值。尝试将 nothing 传递给你的函数的代码甚至不会编译，因此你的函数不必在运行时检查这种情况。另一个例子是使用无符号整数类型（例如 u32），这可以确保参数永远不会为负。
创建用于验证的自定义类型
让我们更进一步地了解使用 Rust 的类型系统来确保我们拥有有效值的想法，并看看创建一个用于验证的自定义类型。回想一下第 2 章中的猜谜游戏，在该游戏中，我们的代码要求用户猜测一个介于 1 到 100 之间的数字。在我们根据秘密数字检查用户猜测之前，我们从未验证过该猜测是否在这些数字之间；我们只验证了猜测是否为正数。在这种情况下，后果并不是很严重：我们输出的“太高”或“太低”仍然是正确的。但这将是一个有用的增强功能，可以引导用户进行有效的猜测，并在用户猜测超出范围的数字时与用户输入字母等情况下的行为有所不同。
一种方法是将猜测解析为 i32 而不是仅解析为 u32 以允许潜在的负数，然后添加对该数字是否在范围内进行检查，如下所示
use rand::Rng;
use std::cmp::Ordering;
use std::io;
fn main() {
println!("Guess the number!");
let secret_number = rand::thread_rng().gen_range(1..=100);
loop {
// --snip--
println!("Please input your guess.");
let mut guess = String::new();
io::stdin()
.read_line(&mut guess)
.expect("Failed to read line");
let guess: i32 = match guess.trim().parse() {
Ok(num) => num,
Err(_) => continue,
};
if guess < 1 || guess > 100 {
println!("The secret number will be between 1 and 100.");
continue;
}
match guess.cmp(&secret_number) {
// --snip--
Ordering::Less => println!("Too small!"),
Ordering::Greater => println!("Too big!"),
Ordering::Equal => {
println!("You win!");
break;
}
}
}
}if 表达式检查我们的值是否超出范围，告知用户问题所在，并调用 continue 以开始循环的下一次迭代并要求另一个猜测。在 if 表达式之后，我们可以继续进行 guess 和秘密数字之间的比较，因为我们知道 guess 在 1 到 100 之间。
但是，这不是一个理想的解决方案：如果绝对关键的是程序仅对 1 到 100 之间的值进行操作，并且它有许多具有此要求的函数，那么在每个函数中都进行这样的检查将非常乏味（并且可能会影响性能）。
相反，我们可以创建一个新类型并将验证放在一个函数中以创建该类型的实例，而不是在所有地方重复验证。这样，函数就可以安全地在它们的签名中使用新类型，并放心地使用它们接收到的值。清单 9-13 显示了一种定义 Guess 类型的方法，该类型仅在 new 函数接收到介于 1 到 100 之间的值时才创建 Guess 的实例。
#![allow(unused)] fn main() { pub struct Guess { value: i32, } impl Guess { pub fn new(value: i32) -> Guess { if value < 1 || value > 100 { panic!("Guess value must be between 1 and 100, got {value}."); } Guess { value } } pub fn value(&self) -> i32 { self.value } } }
清单 9-13：仅处理 1 到 100 之间的值的 Guess 类型
首先，我们定义一个名为 Guess 的结构体，它有一个名为 value 的字段，该字段保存一个 i32。这是存储数字的地方。
然后，我们在 Guess 上实现一个名为 new 的关联函数，该函数创建 Guess 值的实例。new 函数被定义为具有一个名为 value 的参数（类型为 i32）并返回一个 Guess。new 函数主体中的代码测试 value 以确保它在 1 到 100 之间。如果 value 未通过此测试，我们会进行 panic! 调用，这将提醒编写调用代码的程序员他们有一个需要修复的错误，因为使用超出此范围的 value 创建 Guess 将违反 Guess::new 所依赖的约定。Guess::new 可能 panic 的条件应在其面向公众的 API 文档中讨论；我们将在第 14 章介绍指示 API 文档中可能出现 panic! 的文档约定。如果 value 通过了测试，我们将创建一个新的 Guess，将其 value 字段设置为 value 参数，并返回 Guess。
接下来，我们实现一个名为 value 的方法，该方法借用 self，没有任何其他参数，并返回一个 i32。这种方法有时被称为*getter*，因为它的目的是从其字段中获取一些数据并返回它。此公共方法是必需的，因为 Guess 结构体的 value 字段是私有的。value 字段必须是私有的，这一点很重要，这样使用 Guess 结构体的代码就不允许直接设置 value：模块外部的代码*必须*使用 Guess::new 函数来创建 Guess 的实例，从而确保 Guess 不可能具有未经 Guess::new 函数中的条件检查的 value。
然后，具有参数或仅返回 1 到 100 之间的数字的函数可以在其签名中声明它接受或返回 Guess 而不是 i32，并且不需要在其主体中进行任何其他检查。
总结
Rust 的错误处理功能旨在帮助你编写更健壮的代码。panic! 宏表示你的程序处于无法处理的状态，并允许你告诉进程停止，而不是尝试继续处理无效或不正确的值。Result 枚举使用 Rust 的类型系统来指示操作可能会以你的代码可以从中恢复的方式失败。你可以使用 Result 告诉调用你的代码的代码，它还需要处理潜在的成功或失败。在适当的情况下使用 panic! 和 Result 将使你的代码在面对不可避免的问题时更加可靠。
现在你已经看到了标准库将泛型与 Option 和 Result 枚举一起使用的有用方法，我们将讨论泛型的工作原理以及如何在你的代码中使用它们。