9 错误处理

Rust对可靠性的执着也伸到了错误处理

Rust将错误组合成两个主要的类别：可恢复错误和不可恢复错误

大多数语言并不区分这两类错误，并采用类似异常这样的方式统一处理它们，Rust没有异常，但是有可恢复的错误Rust<T,E>,和不可恢复的错误panic

9.3 panic！还是不panic！

前面我们已经了解了panic用来处理不可恢复的错误，Result则可以将各个环节可能遇到的错误以合适的方式返回个调用者，让调用者来决断是否要处理以及如何处理这些错误信息，但是总体而言，适用panic还是比较少的，

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

比如说你要做一个演示示例，那这个时候其实不必要让程序的错误处理代码非常健壮，你也不想看更多的错误信息，那只需要碰到错误就终止程序即可，此时panic比较适合

在我们决定如何处理错误之前，unwrap和expect方法在原型设计时非常方便，我们准备好让程序更加健壮时，它们会在代码中留下清晰的标记

如果测试一个方法，任何一个环节没通过就代表测试失败，我们此时就希望终止测试，此时调用unwrap和expect也是恰当的

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

当我们确定Result的结果会是Ok值时，调用Unwrap也是合适的，虽然编译器无法理解这种逻辑

如果通过人工检查代码来确保永远也不会出现Err值，那么调用unwrap也是完全可以接受的，但是如果因为某些原因我们无法保证代码永远不出现Err值，那就需要用更健壮的方式来处理Result值了

use std::net::IpAddr;fn main() ->Result<(),Box<dyn Error>>{let home:IpAddr = "127.0.0.1".parse().unwrap();
}

错误处理的指导原则

当有可能导致有害状态的的情况下使用panic！有害状态是指一些假设、保证、协议或不可变性被打破的状态，例如无效的值、自相矛盾的值或者被传递了不存在的值，外加如下几种能情形：

有害状态并不包含预期会偶尔发生的错误

在此之后代码的运行依赖不处于这种有害状态

当没有可行的手段来将有害状态信息编码进所使用的类型中的情况

如果别人调用你的代码并传递了一个一个有意义的值，最好的情况也许就是panic！并警告使用你的库的人他的代码中有bug以便他能在开发时就修复它。类似的，你正在调用不受你控制的外部代码，并且它返回了一个你无法修复的无效状态，那么panic往往是合适的

当错误是预期结果之一的时候最好不用panic！因为你可能已经想好了怎么处理这些预期错误了

代码在对值进行操作前，应该首先验证值是有效的，在其无效时panic。为什么？主要出于安全考虑，尝试操作无效数据时会暴露代码漏洞是个安全隐患

Rust类型系统也可以帮助检查错误，例如u32类型永远不会为负

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

loop {let guess :i32 =match guess.trim().parse() {Ok(num) => num,Err(_)=>continue,};if guess <1 || guess >100{println!("The secret number is between 1 and 100");continue;}match guess.com(&secret_number) {}}

我们来改写一下

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}
}

我们创建了一个结构体Guess，里面包含了一个i32类型的字段value

接着我们在Guess实现了一个关联函数new，new的参数是i32类型，返回值是一个Guess类型实例。函数体中当输入的参数不在1到100之内会panic！，并且会继续让函数调用者猜测

我们接着实现了一个借用self的方法value，它没有任何其他参数并返回一个i32，这类方法有时候被称为getter，因为它的目的就是返回对应字段的数据

于是，一个接收（或返回）1到100之间数字的函数就可以声明为接收（或返回）Guess的实例，而不是i32，同时其函数体中也无需进行任何额外的检查

总之合理的利用rust的panic！宏和类型系统可以让我们写出比较健壮的代码