文章目录

Rust的错误处理机制
- Rust还会发生崩溃吗？
- 错误的分类
- - 不可恢复的错误
  - 可恢复的错误
- 传播错误

Rust的错误处理机制

任何语言都需要有错误处理机制，看到主流的语言清一色的try…catch…，Go和Rust又坐不住了，纷纷提出了自己的错误处理机制。Go的错误处理机制被骂的体无完肤，而Rust的错误处理却获赞不少。那么Rust的错误处理有什么独到之处呢，一起来学习一下吧。

Rust还会发生崩溃吗？

即使try…catch…，也有很多不能处理的错误而引发崩溃，是的，任何一种错误处理机制都不可能100%的捕获所有的错误。Rust的内存机制再出色、编译器再强大，也不能保证没有意外的发生。

以最基础的数组越界为例：

fn main() {let a = [1, 2, 3, 4, 5];println!("{}", a[5]);
}

编译器表现得很好，直接器报错：

error: this operation will panic at runtime--> src\main.rs:3:20|
3 |     println!("{}", a[5]);|                    ^^^^ index out of bounds: the len is 5 but the index is 5|= note: `#[deny(unconditional_panic)]` on by defaulterror: aborting due to previous error

很好，那我再换一个写法：

fn main() {let a = [1, 2, 3, 4, 5];let b = 4;println!("{}", a[b+1]);
}

不负众望的编译器还是亮起来红灯：

error: this operation will panic at runtime--> src\main.rs:4:20|
4 |     println!("{}", a[b+1]);|                    ^^^^^^ index out of bounds: the len is 5 but the index is 5|= note: `#[deny(unconditional_panic)]` on by defaulterror: aborting due to previous error

看来我小瞧编译器了。那么，再提升一个难度呢？

use rand::Rng;fn main() {let a = [1, 2, 3, 4, 5];let b = rand::thread_rng().gen_range(5, 999); // 生成一个随机数，这回编译器不知道b的值是多少了println!("{}", a[b]);
}

果然，编译器不是万能的，这次编译通过了，但运行崩溃了：

thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 30', src\main.rs:7:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

可见，强大如rust也没有办法摆脱崩溃的烦恼。

错误的分类

Rust将运行时错误分为两大类：

不可恢复的错误
可恢复的错误

对于大部分错误，并没有严重到无方可解的地步，这个时候，Rest采用Result枚举来解决（还记得吗？内置的枚举类型里有过一面之缘）；然而，对于某些错误，一旦发生就是致命的，此时，Rust提供了一个叫做panic! 的宏，它会在不可恢复的错误发生之后，清理内存数据，然后停止程序的运行。

不可恢复的错误

使用随机数访问数组这个例子就发生了panic，Rust自动调用了panic! 宏，输出中提到了设置RUST_BACKTRACE=1这个环境变量来查看调用堆栈的信息：

thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 451', src\main.rs:7:20
stack backtrace:0: backtrace::backtrace::dbghelp::traceat C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.46\src\backtrace/dbghelp.rs:881: backtrace::backtrace::trace_unsynchronizedat C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.46\src\backtrace/mod.rs:662: std::sys_common::backtrace::_print_fmtat src\libstd\sys_common/backtrace.rs:783: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmtat src\libstd\sys_common/backtrace.rs:594: core::fmt::writeat src\libcore\fmt/mod.rs:10765: std::io::Write::write_fmtat src\libstd\io/mod.rs:15376: std::sys_common::backtrace::_printat src\libstd\sys_common/backtrace.rs:627: std::sys_common::backtrace::printat src\libstd\sys_common/backtrace.rs:498: std::panicking::default_hook::{{closure}}at src\libstd/panicking.rs:1989: std::panicking::default_hookat src\libstd/panicking.rs:21810: std::panicking::rust_panic_with_hookat src\libstd/panicking.rs:48611: rust_begin_unwindat src\libstd/panicking.rs:38812: core::panicking::panic_fmtat src\libcore/panicking.rs:10113: core::panicking::panic_bounds_checkat src\libcore/panicking.rs:7314: guessing::mainat src/main.rs:715: std::rt::lang_start::{{closure}}at C:\Users\zhang\.rustup\toolchains\stable-x86_64-pc-windows-gnu\lib/rustlib/src/rust\src\libstd/rt.rs:6716: std::rt::lang_start_internal::{{closure}}at src\libstd/rt.rs:5217: std::panicking::try::do_callat src\libstd/panicking.rs:29718: std::panicking::tryat src\libstd/panicking.rs:27419: std::panic::catch_unwindat src\libstd/panic.rs:39420: std::rt::lang_start_internalat src\libstd/rt.rs:5121: std::rt::lang_startat C:\Users\zhang\.rustup\toolchains\stable-x86_64-pc-windows-gnu\lib/rustlib/src/rust\src\libstd/rt.rs:6722: main23: _tmainCRTStartup24: mainCRTStartup25: _report_error26: _report_error
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

这个例子太于简单，调用堆栈都是Rust标准库的调用，没有多少有用的信息，如果真正的大型项目，相信还是有用的。

panic! 宏可可以被显式的调用：

fn main() {panic!("我要挂了");
}

可恢复的错误

在前面见到Resut枚举时，用了一个例子，打开一个不存在的文件：

use std::fs::File;fn main() {let f = File::open("hello.txt");match f {Ok(file) => println!("open file success"),Err(error) => println!("open file error:{:?}", error)};
}

File::open返回的是Resutl枚举，Result枚举实现实现了多个方法，如unwrap和expect，它们可以用来简化match：

use std::fs::File;fn main() {let f = File::open("hello.txt").unwrap();
}

在hello.txt不存在的情况下，运行时会有以下输出：

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "系统找不
到指定的文件。" }', src\main.rs:4:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

unwrap内部对open返回的Result进行了模式匹配，如果是Ok，则返回Ok的值，如果是Err，则直接调用panic！。我们希望能看到更多的信息，比如究竟是哪个文件找不到。这时，可以使用expect。expect允许在调用panic！时传入我们自己的信息：

use std::fs::File;fn main() {let f = File::open("hello.txt").expect("can not found file: 'hello.txt'");
}

这段代码输出：

thread 'main' panicked at 'can not found file: 'hello.txt': Os { code: 2, kind: NotFound, message: "系统找不到指定的文件
。" }', src\main.rs:4:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

从编程逻辑上，如果文件不存在，最好的方法是创建它。那么，打开文件失败就一定是文件不存在吗？当然不是，我们可以通过错误类型来判断：

use std::fs::File;
use std::io::ErrorKind;fn main() {let f = File::open("hello.txt");match f {Ok(file) => println!("open file success"),Err(error) => match error.kind() {ErrorKind::NotFound => println!("file not found"),_ => println!("open file error:{:?}", error)}};
}

前面我们已经知道File::open返回一个Result枚举，我们通过match进行模式匹配。error.kind()也返回一个ErrorKind枚举，我们可以通过模式匹配嵌套的方式进行处理。我们已经可以判断是不是因为文件不存在而失败了，再进一步，就可以进行创建文件了。

但是问题来了，创建就一定能成功吗？显示也是不行的，因此，创建文件的函数也返回一个Result枚举：

use std::fs::File;
use std::io::ErrorKind;fn main() {let f = File::open("hello.txt");match f {Ok(file) => println!("open file success"),Err(error) => match error.kind() {ErrorKind::NotFound => match File::create("hello.txt") {Ok(file) => println!("create file success"),Err(e) => println!("create file error: {}", e),},_ => println!("open file error:{:?}", error)}};
}

这段代码可以正常工作，可是三个match嵌套在一起看起来有些不太舒服。我们还可以使用unwrap和expect的变种，以unwrap为例，它有4个变种：

unwrap_err：与unwrap，返回Err的值，当Result是Ok时panic
unwrap_or(default)：如果是Ok，则返回Ok的值，如果是Err返回给定的default
unwrap_or_default：如果是Ok，则返回Ok的值，如果是Err返回Ok相应类型的默认值
unwrap_or_else()：传入一个闭包，如果是Ok，则返回Ok的值，如果是Err则执行这个闭包。我前面写过一篇关于闭包的文章，感兴趣的朋友可以看一下：https://blog.csdn.net/zhmh326/article/details/108443322。

use std::fs::File;
use std::io::ErrorKind;fn main() {let f = File::open("hello.txt").unwrap_or_else(|e| {if e.kind() == ErrorKind::NotFound {File::create("hello.txt").unwrap()} else {panic!("open file error:{:?}", e);}});
}

传播错误

try…catch…有很好的传播特性，当异常发生时，如果不进行处理，它会传播到调用者那里，由调用者处理。Rust的错误处理同样可以实现错误的传播，不过，它不像try…catch…那样是自动的，而是需要将Result类型作为返回值一层层的返回，直到被处理。

比如我们封装一个从文件中读取数据的函数：

use std::io;
use std::io::Read;
use std::fs::File;fn read_file(path: &str) -> Result<String, io::Error> {let mut f = match File::open(path) {Ok(file) => file,Err(e) => return Err(e),};let mut s = String::new();match f.read_to_string(&mut s) {Ok(_) => Ok(s),Err(e) => Err(e),}
}fn main() {println!("file content: {}", read_file("hello.txt").unwrap());
}

read_file函数返回了Result<String, io::Error>类型，在main调用时使用unwrap对其进行处理。事实上，read_file并没有省略对Reuslt的处理，只是将它原样返回了出来。显然这种写法并不友好，这时，可以使用？运算符：

use std::io;
use std::io::Read;
use std::fs::File;fn read_file(path: &str) -> Result<String, io::Error> {let mut f =  File::open(path)?;let mut s = String::new();match f.read_to_string(&mut s) {Ok(_) => Ok(s),Err(e) => Err(e),}
}fn main() {println!("file content: {}", read_file("hello.txt").unwrap());
}

第6行调用File::open后，接了一个?，不再使用match匹配Result，这样的写法如上面的例子是完全等价的，即当Result为Ok时将文件句柄返回给f，当为Err时，函数直接返回Err。read_to_string也可以这么做，甚至，这两次调用可以使用链式表达：

use std::io;
use std::io::Read;
use std::fs::File;fn read_file(path: &str) -> Result<String, io::Error> {let mut s = String::new();File::open(path)?.read_to_string(&mut s)?;Ok(s)
}fn main() {println!("file content: {}", read_file("hello.txt").unwrap());
}

当出现错误时，这两个?都有可能返回Err，没有错误时，返回Ok(s)。