示例、代码原型和测试都非常适合 panic

当你编写一个示例来展示一些概念时，在拥有健壮的错误处理代码的同时也会使得例子不那么明确。例如，调用一个类似 unwrap 这样可能 panic! 的方法可以被理解为一个你实际希望程序处理错误方式的占位符，它根据其余代码运行方式可能会各不相同。
类似地，在我们准备好决定如何处理错误之前，unwrap和expect方法在原型设计时非常方便。当我们准备好让程序更加健壮时，它们会在代码中留下清晰的标记。
如果方法调用在测试中失败了，我们希望这个测试都失败，即便这个方法并不是需要测试的功能。因为 panic! 会将测试标记为失败，此时调用 unwrap 或 expect 是恰当的。

当我们比编译器知道更多的情况

如果通过人工检查代码来确保永远也不会出现 Err 值，那么调用 unwrap 也是完全可以接受的。

  1.     use std::net::IpAddr;
  3.     let home: IpAddr = "127.0.0.1".parse().unwrap();

这里永远不会出错。

错误处理指导原则

下述场景建议使用 panic!

  • 有害状态是非预期的行为，与偶尔会发生的行为相对，比如用户输入了错误格式的数据。
  • 在此之后代码的运行依赖于不处于这种有害状态，而不是在每一步都检查是否有问题。
  • 没有可行的手段来将有害状态信息编码进所使用的类型中的情况。

    创建自定义类型进行有效性验证

    ```rust

![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); }

  1.     Guess { value }
  2. }
  4. pub fn value(&self) -> i32 {
  5.     self.value
  6. }

} } ```