panic! 还是不 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 值，并且编译器仍然会让我们处理 Result，就好像 Err 变体是一种可能性，因为编译器不够聪明，无法看到这个字符串始终是一个有效的 IP 地址。如果 IP 地址字符串来自用户而不是硬编码到程序中，因此*确实*有可能失败，我们肯定希望以更健壮的方式处理 Result。提及此 IP 地址是硬编码的假设将提示我们，如果将来我们需要从其他来源获取 IP 地址，则将 expect 更改为更好的错误处理代码。
错误处理指南
当你的代码有可能最终处于糟糕的状态时，建议让你的代码发生 panic。在这种情况下，“糟糕的状态”是指某些假设、保证、契约或不变量被打破，例如当无效值、矛盾值或缺失值传递给你的代码时，以及以下一个或多个情况：
- 糟糕的状态是意料之外的事情，而不是像用户输入格式错误的数据那样偶尔会发生的事情。
- 此后的代码需要依赖于不处于这种糟糕的状态，而不是在每个步骤中都检查问题。
- 没有好的方法将此信息编码到你使用的类型中。我们将在第 17 章的 “将状态和行为编码为类型” 部分中详细说明我们的意思。第 17 章。
如果有人调用你的代码并传入没有意义的值，最好尽可能返回一个错误，以便库的用户可以决定在这种情况下他们想要做什么。但是，在继续操作可能不安全或有害的情况下，最好的选择可能是调用 panic! 并提醒使用你的库的人他们的代码中存在错误，以便他们可以在开发过程中修复它。同样，如果你正在调用你无法控制的外部代码，并且它返回你无法修复的无效状态，那么 panic! 通常是合适的。
但是，当预期会发生失败时，返回 Result 比调用 panic! 更合适。示例包括解析器被赋予格式错误的数据或 HTTP 请求返回指示你已达到速率限制的状态。在这些情况下，返回 Result 表示失败是预期的可能性，调用代码必须决定如何处理。
当你的代码执行如果使用无效值调用可能会使用户面临风险的操作时，你的代码应首先验证值是否有效，如果值无效则发生 panic。这主要是出于安全原因：尝试对无效数据进行操作可能会使你的代码容易受到攻击。这就是标准库在您尝试超出范围的内存访问时会调用 panic! 的主要原因：尝试访问不属于当前数据结构的内存是一个常见的安全问题。函数通常有*契约*：只有当输入满足特定要求时，才能保证它们的行为。当契约被违反时发生 panic 是有道理的，因为契约违反始终表明调用方存在错误，这不是您希望调用代码必须显式处理的错误类型。事实上，调用代码没有合理的恢复方式；调用*程序员*需要修复代码。函数的契约，特别是当违反会导致 panic 时，应在函数的 API 文档中解释。
但是，在所有函数中进行大量错误检查会很冗长且烦人。幸运的是，你可以使用 Rust 的类型系统（以及编译器完成的类型检查）来为你执行许多检查。如果你的函数具有特定类型作为参数，你可以继续使用你的代码逻辑，因为你知道编译器已经确保你有一个有效的值。例如，如果你有一个类型而不是一个 Option，你的程序期望有*某些东西*而不是*什么都没有*。然后，你的代码不必处理 Some 和 None 变体的两种情况：它只会有一种肯定有一个值的情况。试图将什么都不传递给你的函数的代码甚至不会编译，因此你的函数不必在运行时检查这种情况。另一个例子是使用无符号整数类型（例如 u32），这确保了参数永远不会为负数。
创建用于验证的自定义类型
让我们进一步考虑使用 Rust 的类型系统来确保我们有一个有效的值，并看看如何创建用于验证的自定义类型。回想一下第 2 章中的猜谜游戏，其中我们的代码要求用户猜测一个介于 1 到 100 之间的数字。在将其与我们的秘密数字进行比较之前，我们从未验证用户的猜测是否在该数字之间；我们只验证了猜测是否为正数。在这种情况下，后果不是很严重：我们的输出“太高”或“太低”仍然是正确的。但是，指导用户进行有效猜测，并在用户猜测超出范围的数字时与用户输入（例如）字母时有不同的行为，这将是一个有用的增强。
一种方法是将猜测解析为 i32 而不仅仅是 u32 以允许潜在的负数，然后添加一个检查以查看数字是否在范围内，如下所示
文件名：src/main.rs
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 的实例。
文件名：src/lib.rs
#![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：Guess 类型仅会继续使用 1 到 100 之间的值
首先，我们定义一个名为 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 枚举的有用方法，我们将讨论泛型的工作原理以及如何在你的代码中使用它们。