完成了最基本的文本文件搜索功能，下一步就是让项目的错误处理更优雅。
欢迎来到我的 Rust 命令行软件开发入门教程第三篇，如果你还没看过上篇文章的内容，欢迎查看。
也欢迎关注这个系列专栏，我将更新更多精彩内容。
1. 初版实现代码拆解
上篇文章结束时，我们实现了grrs的基本功能，给出了第一版实现方案：
use clap::Parser;
/// Search for a pattern in a file and display the lines that contain it.
#[derive(Parser)]
struct Cli {
/// The pattern to look for
pattern: String,
/// The path to the file to read
path: std::path::PathBuf,
}
fn main() {
let args = Cli::parse();
let content = std::fs::read_to_string(&args.path).expect("could not read file");
for line in content.lines() {
if line.contains(&args.pattern) {
println!("{}", line);
}
}
}
我们已经详细讨论过和Cli结构体相关的信息，现在，请大家将注意力集中在main函数上。
在完成参数解析后，我们使用content来储存被查询文件的内容。这个文件读取的过程是怎样的呢？
注意到，我们调用了标准库中的std::fs::read_to_string函数，并且给这个函数传入了&args.path，也就是刚刚我们读取的文件路径。
这里的&符号表示的是引用，因为这里我们无需向函数转移args的所有权。这是rust语言的内存管理机制之一，如果还不是很熟悉的朋友可以再查阅一下官方语言教程。
这里就有个问题：要是用户传入的文件根本不存在，怎么办？显然，这是有可能的。
比如：
目前这个版本，是在完成这个函数之后链式调用了另一个函数：.expect()。这个函数的作用是，如果出现了无法读取的路径，立刻崩溃退出程序。显然，这不算是一种足够优雅的错误处理办法。
2. 理解Result和模式匹配
为能够更好实现错误处理，我们必须理解read_to_string到底返回了什么。实际上，返回的是一个Result<String, Error>结构。
Result<T, E>是rust语言中一种用于辅助错误处理的独特枚举结构，返回的结果既可以是包含成功值的Ok(T)，也可以是包含错误信息的Err(E)。
在这里，我们可以使用模式匹配来完成对这个函数结果的处理，比如：
let result = std::fs::read_to_string("nonexistent.txt");
match result {
Ok(content) => { println!("File content: {}", content); }
Err(error) => { println!("Oh noes: {}", error); }
}
就像拆快递一样，模式匹配会拆开Result这个包裹：如果是Ok就取出值，如果是Err就处理错误。如果你之前有过函数式语言的经历，这样的模式匹配语法相信你一定倍感亲切。
利用这种机制，我们可以稍稍改写一下之前的代码。
3. 通过unwrap进行错误处理
再rust中，panic!宏可以让程序立刻崩溃并退出。所以，开头我们的代码也可以这么写：
let result = std::fs::read_to_string("nonexistent.txt");
let content = match result {
Ok(content) => { content },
Err(error) => { panic!("Can't deal with {}, just exit here", error); }
};
println!("file content: {}", content);
简单来说，就是如果Ok()那么我们继续，如果不幸报Err()那么我们立即崩溃退出。
实际上，这还有一种简写版代码：
let content = std::fs::read_to_string("nonexistent.txt").unwrap();
我们把所有这个代码整合进本来的main函数：
fn main() {
let args = Cli::parse();
let content = std::fs::read_to_string("nonexistent.txt").unwrap();
for line in content.lines() {
if line.contains(&args.pattern) {
println!("{}", line);
}
}
}
尝试执行一个不存在的命令，我们会看到：
和我们预计的一样，程序在读取文件失败后立即崩溃退出。
事实上，这也就是为什么大家经常看到提醒，生产环境中一定要慎用unwrap()函数。
除非我们十分确认程序不会崩溃，或者像目前我们的程序一样，崩溃了不会产生太严重的后果，否则尽量不要使用这个函数，还是深思熟虑一下如何进行错误处理吧。
4. 更优雅的无panic错误处理
你可能会说，那这个unwrap还是立刻崩溃退出，没什么区别啊。别着急，铺垫这么多就是为了最后这一步优化的。
既然直接退出不好，而结果可能成功也可能有报错，那我们为什么不也使用一个Result呢？
请看示例代码：
fn main() -> Result<(), Box<dyn std::error::Error>> {
let result = std::fs::read_to_string("nonexistent.txt");
let content = match result {
Ok(content) => { content },
Err(error) => { return Err(error.into()); }
};
println!("file content: {}", content);
Ok(())
}
这里，如果说result结果是报错，我们不会崩溃结束程序，而是返回一个Err(error.into())值。反之，则返回Ok(())。
你可能注意到最后的Ok(())前没有用关键字return。事实上，由于rust中所有由大括号包裹的代码块最后一行都是默认返回值，这里我们可以简写忽略return。
rust需要开发者对所有有返回值的函数进行详细的类型标注。这里，我们看到返回类型是Result<(), Box<dyn std::error::Error>>。
这里的Box<dyn std::error::Error>实际上是一种可以存储任何错误的“盒子”，只要该错误类型实现了Error trait。而main函数中的error.into()实际上在做类型转换，将原本的 Error 转换为我们指定的Box<dyn Error>结构。
如果你不确定这段讨论的细节，没关系，继续往下读，这不影响我们后续的开发。
事实上，和unwrap一样，我们刚刚通过模式匹配完成的错误处理也有一种简写法：
let content = std::fs::read_to_string("nonexistent.txt")?;
对，你没看错，只是加了个问号?就搞定了，这个?就是等同于match模式匹配 +return Err(error.into)的语法糖。是不是很方便呢？
5. 总结
现在，我们将刚刚学会的?上抛错误法整合进项目，你应该得到的完整项目代码是：
use clap::Parser;
/// Search for a pattern in a file and display the lines that contain it.
#[derive(Parser)]
struct Cli {
/// The pattern to look for
pattern: String,
/// The path to the file to read
path: std::path::PathBuf,
}
fn main() -> Result<(), Box<dyn std::error::Error>> {
let args = Cli::parse();
let content = std::fs::read_to_string(&args.path)?;
for line in content.lines() {
if line.contains(&args.pattern) {
println!("{}", line);
}
}
Ok(())
}
我们尝试一个可以成功执行的搜索命令：
再尝试一个应当报错的命令：
可以看到，之前一直有的程序崩溃提示，现在就不存在了！在错误处理上，我们向前走了坚实的一步。
在rust中，?是传播错误传播的惯用方式。如果你之前有过别的编程语言的经验，你应当发现这种错误处理方式比一般的try...catch...finally甚至if err != nil要方便的多，对，说的就是你，golang。
不知道本文所讲的Result类型和?上抛错误的方式，你是否学会了呢？
到这里，我们会发现出错以后返回的 Error 是Debug格式展示的，对于开发者来说没什么问题，但对终端用户不够友好。
下篇文章，我将聊聊如何让命令行应用的输出结果更优美。
希望这篇博客能帮助到你，也欢迎关注交流。愿与君共勉！