From 038c27495d6cc30a2b85e00b8a0f6b7beb4f157b Mon Sep 17 00:00:00 2001 From: KaiserY Date: Mon, 10 Apr 2017 16:25:42 +0800 Subject: [PATCH] wip: update ch12-03 --- docs/ch05-00-structs.html | 2 +- docs/ch05-01-method-syntax.html | 4 +- docs/ch06-01-defining-an-enum.html | 2 +- ...proving-error-handling-and-modularity.html | 293 ++++++++++------ docs/ch17-01-what-is-oo.html | 15 + docs/print.html | 320 +++++++++++------ ...improving-error-handling-and-modularity.md | 329 ++++++++++++------ 7 files changed, 624 insertions(+), 341 deletions(-) diff --git a/docs/ch05-00-structs.html b/docs/ch05-00-structs.html index 0064797..4e2b6bf 100644 --- a/docs/ch05-00-structs.html +++ b/docs/ch05-00-structs.html @@ -212,7 +212,7 @@ fn area(rectangle: &Rectangle) -> u32 {

这里我们定义了一个结构体并称其为Rectangle。在{}中定义了字段length和width，都是u32类型的。接着在main中，我们创建了一个长度为 50 和宽度为 30 的Rectangle的具体实例。

函数area现在被定义为接收一个名叫rectangle的参数，它的类型是一个结构体Rectangle实例的不可变借用。第四章讲到过，我们希望借用结构体而不是获取它的所有权这样main函数就可以保持rect1的所有权并继续使用它，所以这就是为什么在函数签名和调用的地方会有&。

-

area函数访问Rectangle的length和width字段。area的签名现在明确的表明了我们的意图：通过其length和width字段，计算一个Rectangle的面积，。这表明了长度和宽度是相互联系的，并为这些值提供了描述性的名称而不是使用元组的索引值0和1。这是明确性的胜利。

+

area函数访问Rectangle的length和width字段。area的签名现在明确的表明了我们的意图：通过其length和width字段，计算一个Rectangle的面积，。这表明了长度和宽度是相互联系的，并为这些值提供了描述性的名称而不是使用元组的索引值0和1。结构体胜在更清晰明了。

通过衍生 trait 增加实用功能

如果能够在调试程序时打印出Rectangle实例来查看其所有字段的值就更好了。列表 5-5 尝试像往常一样使用println!宏：

Filename: src/main.rs

diff --git a/docs/ch05-01-method-syntax.html b/docs/ch05-01-method-syntax.html index 53baf5a..9529046 100644 --- a/docs/ch05-01-method-syntax.html +++ b/docs/ch05-01-method-syntax.html @@ -103,7 +103,7 @@ struct

为了使函数定义于Rectangle的上下文中，我们开始了一个impl块（impl是 implementation 的缩写）。接着将函数移动到impl大括号中，并将签名中的第一个（在这里也是唯一一个）参数和函数体中其他地方的对应参数改成self。然后在main中将我们调用area方法并传递rect1作为参数的地方，改成使用方法语法在Rectangle实例上调用area方法。方法语法获取一个实例并加上一个点号后跟方法名、括号以及任何参数。

在area的签名中，开始使用&self来替代rectangle: &Rectangle，因为该方法位于impl Rectangle 上下文中所以 Rust 知道self的类型是Rectangle。注意仍然需要在self前面加上&，就像&Rectangle一样。方法可以选择获取self的所有权，像我们这里一样不可变的借用self，或者可变的借用self，就跟其他别的参数一样。

-

这里选择&self跟在函数版本中使用&Rectangle出于同样的理由：我们并不想获取所有权，只希望能够读取结构体中的数据，而不是写入。如果想要能够在方法中改变调用方法的实例的话，需要将抵押给参数改为&mut self。通过仅仅使用self作为第一个参数来使方法获取实例的所有权，不过这是很少见的；这通常用在当方法将self转换成别的实例的时候，同时我们想要防止调用者在转换之后使用原始的实例。

+

这里选择&self跟在函数版本中使用&Rectangle出于同样的理由：我们并不想获取所有权，只希望能够读取结构体中的数据，而不是写入。如果想要能够在方法中改变调用方法的实例的话，需要将第一个参数改为&mut self。通过仅仅使用self作为第一个参数来使方法获取实例的所有权，不过这是很少见的；这通常用在当方法将self转换成别的实例的时候，同时我们想要防止调用者在转换之后使用原始的实例。

使用方法而不是函数，除了使用了方法语法和不需要在每个函数签名中重复self类型外，其主要好处在于组织性。我将某个类型实例能做的所有事情都一起放入impl块中，而不是让将来的用户在我们的代码中到处寻找Rectangle的功能。

@@ -130,7 +130,7 @@ struct

p1.distance(&p2); (&p1).distance(&p2); -

第一行看起来简洁的多。这种自动引用的行为之所以能行得通是因为方法有一个明确的接收者————self的类型。在给出接收者和方法名的前提下，Rust 可以明确的计算出方法是仅仅读取（所以需要&self），做出修改（所以是&mut self）或者是获取所有权（所以是self）。Rust 这种使得借用对方法接收者来说是隐式的做法是其所有权系统人体工程学实践的一大部分。

+

第一行看起来简洁的多。这种自动引用的行为之所以能行得通是因为方法有一个明确的接收者————self的类型。在给出接收者和方法名的前提下，Rust 可以明确的计算出方法是仅仅读取（所以需要&self），做出修改（所以是&mut self）或者是获取所有权（所以是self）。Rust 这种使得借用对方法接收者来说是隐式的做法是其所有权系统程序员友好性实现的一大部分。

带有更多参数的方法

 diff --git a/docs/ch06-01-defining-an-enum.html b/docs/ch06-01-defining-an-enum.html index dc79f68..0e19f5c 100644 --- a/docs/ch06-01-defining-an-enum.html +++ b/docs/ch06-01-defining-an-enum.html @@ -156,7 +156,7 @@ let home = IpAddr::V4(127, 0, 0, 1); let loopback = IpAddr::V6(String::from("::1")); -

这些代码展示了使用枚举来储存两种不同 IP 地址的几种可能的选择。然而，事实证明储存和编码 IP 地址实在是太常见了以致标准库提供了一个可供使用的定义！让我们看看标准库如何定义IpAddr的：它正有着跟我们定义和使用的一样的枚举和成员，不过它将成员种的地址数据嵌入到了两个不同形式的结构体中，他们对不同的成员的定义是不同的：

+

这些代码展示了使用枚举来储存两种不同 IP 地址的几种可能的选择。然而，事实证明储存和编码 IP 地址实在是太常见了以致标准库提供了一个可供使用的定义！让我们看看标准库如何定义IpAddr的：它正有着跟我们定义和使用的一样的枚举和成员，不过它将成员中的地址数据嵌入到了两个不同形式的结构体中，他们对不同的成员的定义是不同的：

struct Ipv4Addr {
     // details elided
 }
diff --git a/docs/ch12-03-improving-error-handling-and-modularity.html b/docs/ch12-03-improving-error-handling-and-modularity.html
index 1c06d81..cc72436 100644
--- a/docs/ch12-03-improving-error-handling-and-modularity.html
+++ b/docs/ch12-03-improving-error-handling-and-modularity.html
@@ -67,7 +67,7 @@
                 
 
                 

-                    
读取文件

+                    
重构改进模块性和错误处理

 

 
ch12-03-improving-error-handling-and-modularity.md
 

@@ -80,57 +80,73 @@ commit b8e4fcbf289b82c12121b282747ce05180afb1fb

 
第四，我们不停的使用expect来处理不同的错误，如果用户没有指定足够的参数来运行程序，他们会从 Rust 得到 "index out of bounds" 错误而这并不能明确的解释问题。如果所有的错误处理都位于一处这样将来的维护者在需要修改错误处理逻辑时就只需要咨询一处代码。将所有的错误处理都放在一处也有助于确保我们打印的错误信息对终端用户来说是有意义的。

 
让我们通过重构项目来解决这些问题。

 
二进制项目的关注分离

-
这类项目组织上的问题在很多相似类型的项目中很常见，所以 Rust 社区开发出一种关注分离的组织模式。这种模式可以用来组织任何用 Rust 构建的二进制项目，所以可以证明应该更早的开始这项重构，以为我们的项目符合这个模式。这个模式看起来像这样：

+
main函数负责多个任务的组织问题在许多二进制项目中很常见。所以 Rust 社区开发出一个类在main函数开始变得庞大时进行二进制程序的关注分离的指导性过程。这些过程有如下步骤：

 
    
-
  1. 将程序拆分成 main.rs 和 lib.rs。
    2. 
-
  2. 将命令行参数解析逻辑放入 main.rs。
    3. 
-
  3. 将程序逻辑放入 lib.rs。
    4. 
-
  4. main函数的工作是：
+
  5. 将程序拆分成 main.rs 和 lib.rs 并将程序的逻辑放入 lib.rs 中。
    6. 
+
  6. 当命令行解析逻辑比较小时，可以保留在 main.rs 中。
    7. 
+
  7. 当命令行解析开始变得复杂时，也同样将其从 main.rs 提取到 lib.rs中。
    8. 
+
  8. 经过这些过程之后保留在main函数中的责任是：
 
      
-
    • 解析参数
      • 
-
    • 设置所有配置性变量
      • 
+
    • 使用参数值调用命令行解析逻辑
      • 
+
    • 设置任何其他的配置
      • 
 
    • 调用 lib.rs 中的run函数
      • 
-
    • 如果run返回错误则处理这个错误
      • 
+
    • 如果run返回错误，则处理这个错误
      • 
 
    
 
    9. 
 

-
好的！老实说这个模式好像还很复杂。这就是关注分离的所有内容：main.rs 负责实际的程序运行，而 lib.rs 处理所有真正的任务逻辑。让我们将程序重构成这种模式。首先，提取出一个目的只在于解析参数的函数。列表 12-4 中展示了一个新的开始，main函数调用了一个新函数parse_config，它仍然定义于 src/main.rs 中：

+
这个模式的一切就是为了关注分离：main.rs 处理程序运行，而 lib.rs 处理所有的真正的任务逻辑。因为不能直接测试main函数，这个结构通过将所有的程序逻辑移动到 lib.rs 的函数中使得我们可以测试他们。仅仅保留在 main.rs 中的代码将足够小以便阅读就可以验证其正确性。

+
+
+
提取参数解析器

+
首先，我们将提取解析参数的功能。列表 12-5 中展示了新main函数的开头，它调用了新函数parse_config。目前它仍将定义在 src/main.rs 中：

 
Filename: src/main.rs

 
fn main() {
     let args: Vec<String> = env::args().collect();
 
-    let (search, filename) = parse_config(&args);
-
-    println!("Searching for {}", search);
-    println!("In file {}", filename);
+    let (query, filename) = parse_config(&args);
 
     // ...snip...
 }
 
 fn parse_config(args: &[String]) -> (&str, &str) {
-    let search = &args[1];
+    let query = &args[1];
     let filename = &args[2];
 
-    (search, filename)
+    (query, filename)
 }
 

-
Listing 12-4: Extract a parse_config function from
+
Listing 12-5: Extract a parse_config function from
 main

 
-
这看起来好像有点复杂，不过我们将一点一点的开展重构。在做出这些改变之后，再次运行程序并验证参数解析是否仍然正常。经常验证你的进展是一个好习惯，这样在遇到问题时就能更好地理解什么修改造成了错误。

+
我们仍然将命令行参数收集进一个 vector，不过不同于在main函数中将索引 1 的参数值赋值给变量query和将索引 2 的值赋值给变量filename，我们将整个 vector 传递给parse_config函数。接着parse_config函数将包含知道哪个参数该放入哪个变量的逻辑，并将这些值返回到main。仍然在main中创建变量query和filename，不过main不再负责处理命令行参数与变量如何对应。

+
这对我们这小程序可能有点大材小用，不过我们将采用小的、增量的步骤进行重构。在做出这些改变之后，再次运行程序并验证参数解析是否仍然正常。经常验证你的进展是一个好习惯，这样在遇到问题时能帮助你定位问题的成因。

 
组合配置值

-
现在我们有了一个函数了，让我们接着完善它。我们代码还能设计的更好一些：函数返回了一个元组，不过接着立刻就解构成了单独的部分。这些代码本身没有问题，不过有一个地方表明仍有改善的余地：我们调用了parse_config方法。函数名中的config部分也表明了返回的两个值应该是组合在一起的，因为他们都是某个配置值的一部分。

+
我们可以采取另一个小的步骤来进一步改善这个函数。现在函数返回一个元组，不过立刻又就将元组拆成了独立的部分。这是一个我们可能没有进行正确抽象的信号。

+
另一个表明还有改进空间的迹象是parse_config的config部分，它暗示了我们返回的两个值是相关的并都是一个配置值的一部分。目前除了将这两个值组合进元组之外并没有表达这个数据结构的意义：我们可以将这两个值放入一个结构体并给每个字段一个有意义的名字。这会让未来的维护者更容易理解不同的值如何相互关联以及他们的目的。

+
 

-
注意：一些同学将当使用符合类型更为合适的时候使用基本类型当作一种称为基本类型偏执（primitive obsession）的反模式。

+
注意：一些同学将这种当使用符合类型更为合适的时候使用基本类型的反模式称为基本类型偏执（primitive obsession）。

 

-
让我们引入一个结构体来存放所有的配置。列表 12-5 中展示了新增的Config结构体定义、重构后的parse_config和main函数中的相关更新：

+
+
+
列表 12-6 展示了新定义的结构体Config，它有字段query和filename。我们也改变了parse_config函数来返回一个Config结构体的实例，并更新main来使用结构体字段而不是单独的变量：

 
Filename: src/main.rs

-
fn main() {
+
# use std::env;
+# use std::fs::File;
+#
+fn main() {
     let args: Vec<String> = env::args().collect();
 
     let config = parse_config(&args);
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     let mut f = File::open(config.filename).expect("file not found");
@@ -139,88 +155,121 @@ fn parse_config(args: &[String]) -> (&str, &str) {
 }
 
 struct Config {
-    search: String,
+    query: String,
     filename: String,
 }
 
 fn parse_config(args: &[String]) -> Config {
-    let search = args[1].clone();
+    let query = args[1].clone();
     let filename = args[2].clone();
 
     Config {
-        search: search,
+        query: query,
         filename: filename,
     }
 }
 

-
Listing 12-5: Refactoring parse_config to return an
-instance of a Config struct

+
Listing 12-6: Refactoring parse_config to return an instance of a Config
+struct

 
-
parse_config的签名现在表明它返回一个Config值。在parse_config的函数体中，我们之前返回了args中String值引用的字符串 slice，不过Config定义为拥有两个有所有权的String值。因为parse_config的参数是一个String值的 slice，Config实例不能获取String值的所有权：这违反了 Rust 的借用规则，因为main函数中的args变量拥有这些String值并只允许parse_config函数借用他们。

-
还有许多不同的方式可以处理String的数据；现在我们使用简单但低效率的方式，在字符串 slice 上调用clone方法。clone调用会生成一个字符串数据的完整拷贝，而且Config实例可以拥有它，不过这会消耗更多时间和内存来储存拷贝字符串数据的引用，不过拷贝数据让我们使我们的代码显得更加直白。

+
parse_config的签名现在表明它返回一个Config值。在parse_config的函数体中，之前返回了args中String值引用的字符串 slice，现在我们选择定义Config来使用拥有所有权的String值。main中的args变量是参数值的所有者并只允许parse_config函数借用他们，这意味着如果Config尝试获取args中值的所有权将违反 Rust 的借用规则。

+
还有许多不同的方式可以处理String的数据，而最简单但有些不太高效的方式是调用这些值的clone方法。这会生成Config实例可以拥有的数据的完整拷贝，不过会比储存字符串数据的引用消耗更多的时间和内存。不过拷贝数据使得代码显得更加直白因为无需管理引用的生命周期，所以在这种情况下牺牲一小部分性能来换取简洁性的取舍是值得的。

 
 

 
使用clone权衡取舍

-
由于其运行时消耗，许多 Rustacean 之间有一个趋势是倾向于不使用clone来解决所有权问题。在关于迭代器的第十三章中，我们将会学习如何更有效率的处理这种情况。现在，为了编写我们的程序拷贝一些字符串是没有问题。我们只进行了一次拷贝，而且文件名和要搜索的字符串都比较短。随着你对 Rust 更加熟练，将更轻松的省略这个权衡的步骤，不过现在调用clone是完全可以接受的。

+
由于其运行时消耗，许多 Rustacean 之间有一个趋势是倾向于避免使用clone来解决所有权问题。在关于迭代器的第十三章中，我们将会学习如何更有效率的处理这种情况，不过现在，复制一些字符串来取得进展是没有问题的，因为只会进行一次这样的拷贝，而且文件名和要搜索的字符串都比较短。在第一轮编写时拥有一个可以工作但有点低效的程序要比尝试过度优化代码更好一些。随着你对 Rust 更加熟练，将能更轻松的直奔合适的方法，不过现在调用clone是完全可以接受的。

 

 
-
main函数更新为将parse_config返回的Config实例放入变量config中，并将分别使用search和filename变量的代码更新为使用Config结构体的字段。

+
我们更新main将parse_config返回的Config实例放入变量config中，并更新之前分别使用search和filename变量的代码为现在的使用Config结构体的字段。

+
现在代码更明确的表现了我们的意图，query和filename是相关联的并且他们的目的是配置程序如何工作的。任何使用这些值的代码就知道在config实例中对应目的的字段名中寻找他们。

 
创建一个Config构造函数

-
现在让我们考虑一下parse_config的目的：这是一个创建Config示例的函数。我们已经见过了一个创建实例函数的规范：像String::new这样的new函数。列表 12-6 中展示了将parse_config转换为一个Config结构体关联函数new的代码：

+
+
+
目前为止，我们将负责解析命令行参数的逻辑从main提取到了parse_config函数中，这帮助我们看清值query和filename是相互关联的并应该在代码中表现这种关系。接着我们增加了Config结构体来命名query和filename的相关目的，并能够从parse_config函数中将这些值的名称作为结构体字段名称返回。

+
所以现在parse_config函数的目的是创建一个Config实例，我们可以将parse_config从一个普通函数变为一个叫做new的与结构体关联的函数。做出这个改变使得代码更符合习惯：可以像标准库中的String调用String::new来创建一个该类型的实例那样，将parse_config变为一个与Config关联的new函数。列表 12-7 展示了需要做出的修改：

 
Filename: src/main.rs

-
fn main() {
+
# use std::env;
+#
+fn main() {
     let args: Vec<String> = env::args().collect();
 
     let config = Config::new(&args);
 
-    println!("Searching for {}", config.search);
-    println!("In file {}", config.filename);
-
     // ...snip...
 }
 
+# struct Config {
+#     query: String,
+#     filename: String,
+# }
+#
 // ...snip...
 
 impl Config {
     fn new(args: &[String]) -> Config {
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Config {
-            search: search,
+            query: query,
             filename: filename,
         }
     }
 }
 

-
Listing 12-6: Changing parse_config into
+
Listing 12-7: Changing parse_config into
 Config::new

 
-
我们将parse_config的名字改为new并将其移动到impl块中。我们也更新了main中的调用代码。再次尝试编译并确保程序可以运行。

-
从构造函数返回Result

-
这是我们对这个方法最后的重构：还记得当 vector 含有少于三个项时访问索引 1 和 2 会 panic 并给出一个糟糕的错误信息的代码吗？让我们来修改它！列表 12-7 展示了如何在访问这些位置之前检查 slice 是否足够长，并使用一个更好的 panic 信息：

+
这里将main中调用parse_config的地方更新为调用Config::new。我们将parse_config的名字改为new并将其移动到impl块中，这使得new函数与Config相关联。再次尝试编译并确保它可以工作。

+
修复错误处理

+
现在我们开始修复错误处理。回忆一下之前提到过如果args vector 包含少于 3 个项并尝试访问 vector 中索引 1 或 索引 2 的值会造成程序 panic。尝试不带任何参数运行程序；这将看起来像这样：

+
$ cargo run
+    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
+     Running `target/debug/greprs`
+thread 'main' panicked at 'index out of bounds: the len is 1
+but the index is 1',  /stable-dist-rustc/build/src/libcollections/vec.rs:1307
+note: Run with `RUST_BACKTRACE=1` for a backtrace.
+

+
index out of bounds: the len is 1 but the index is 1是一个针对程序员的错误信息，这并不能真正帮助终端用户理解发生了什么和相反他们应该做什么。现在就让我们修复它吧。

+
改善错误信息

+
在列表 12-8 中，在new函数中增加了一个检查在访问索引 1 和 2 之前检查 slice 是否足够长。如果 slice 不够长，我们使用一个更好的错误信息 panic 而不是index out of bounds信息：

 
Filename: src/main.rs

 
// ...snip...
 fn new(args: &[String]) -> Config {
     if args.len() < 3 {
         panic!("not enough arguments");
     }
-
-    let search = args[1].clone();
     // ...snip...
-}
 

-
Listing 12-7: Adding a check for the number of
+
Listing 12-8: Adding a check for the number of
 arguments

 
-
通过在new中添加这额外的几行代码，再次尝试不带参数运行程序：

+
这类似于列表 9-8 中的Guess::new函数，那里如果value参数超出了有效值的范围就调用panic!。不同于检查值的范围，这里检查args的长度至少是 3，而函数的剩余部分则可以假设这个条件成立的基础上运行。如果
+args少于 3 个项，这个条件将为真，并调用panic!立即终止程序。

+
有了new中这几行额外的代码，再次不带任何参数运行程序并看看现在错误看起来像什么：

 
$ cargo run
     Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target\debug\greprs.exe`
-thread 'main' panicked at 'not enough arguments', src\main.rs:29
+     Running `target/debug/greprs`
+thread 'main' panicked at 'not enough arguments', src/main.rs:29
 note: Run with `RUST_BACKTRACE=1` for a backtrace.
 

-
这样就好多了！至少有个一个符合常理的错误信息。然而，还有一堆额外的信息我们并不希望提供给用户。可以通过改变new的签名来完善它。现在它只返回了一个Config，所有没有办法表示创建Config失败的情况。相反，可以如列表 12-8 所示返回一个Result：

+
这个输出就好多了，现在有了一个合理的错误信息。然而，我们还有一堆额外的信息不希望提供给用户。所以在这里使用列表 9-8 中的技术可能不是最好的；无论如何panic!调用更适合程序问题而不是使用问题，正如第九章所讲到的。相反我们可以使用那一章学习的另一个技术：返回一个可以表明成功或错误的Result。

+
+
+
从new中返回Result而不是调用panic!

+
我们可以选择返回一个Result值，它在成功时会包含一个Config的实例，而在错误时会描述问题。当Config::new与main交流时，在使用Result类型存在问题时可以使用 Rust 的信号方式。接着修改main将Err成员转换为对用户更友好的错误，而不是panic!调用产生的关于thread 'main'和RUST_BACKTRACE的文本。

+
列表 12-9 展示了Config::new返回值和函数体中返回Result所需的改变：

 
Filename: src/main.rs

 
impl Config {
     fn new(args: &[String]) -> Result<Config, &'static str> {
@@ -228,25 +277,28 @@ note: Run with `RUST_BACKTRACE=1` for a backtrace.
             return Err("not enough arguments");
         }
 
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Ok(Config {
-            search: search,
+            query: query,
             filename: filename,
         })
     }
 }
 

-
Listing 12-8: Return a Result from Config::new

+
Listing 12-9: Return a Result from Config::new

 
-
现在new函数返回一个Result，在成功时带有一个Config实例而在出现错误时带有一个&'static str。回忆一下第十章“静态声明周期”中讲到&'static str是一个字符串字面值，他也是现在我们的错误信息。

+
+
+
现在new函数返回一个Result，在成功时带有一个Config实例而在出现错误时带有一个&'static str。回忆一下第十章“静态声明周期”中讲到&'static str是一个字符串字面值，也是目前的错误信息。

 
new函数体中有两处修改：当没有足够参数时不再调用panic!，而是返回Err值。同时我们将Config返回值包装进Ok成员中。这些修改使得函数符合其新的类型签名。

-
Config::new调用和错误处理

-
现在我们需要对main做一些修改，如列表 12-9 所示：

+
通过让Config::new返回一个Err值，这就允许main函数处理new函数返回的Result值并在出现错误的情况更明确的结束进程。

+
Config::new调用并处理错误

+
为了处理错误情况并打印一个对用户友好的信息，我们需要像列表 12-10 那样更新main函数来处理现在Config::new返回的Result。另外还需要实现一些panic!替我们处理的问题：使用错误码 1 退出命令行工具。非零的退出状态是一个告诉调用程序的进程我们的程序以错误状态退出的惯例信号。

 
Filename: src/main.rs

-
// ...snip...
-use std::process;
+
use std::process;
 
 fn main() {
     let args: Vec<String> = env::args().collect();
@@ -256,31 +308,46 @@ fn main() {
         process::exit(1);
     });
 
-    println!("Searching for {}", config.search);
-    println!("In file {}", config.filename);
-
     // ...snip...
 

-
Listing 12-9: Exiting with an error code if creating a
+
Listing 12-10: Exiting with an error code if creating a
 new Config fails

 
-
新增了一个use行来从标准库中导入process。在main函数中我们将处理new函数返回的Result值，并在其返回Config::new时以一种更加清楚的方式结束进程。

-
这里使用了一个之前没有讲到的标准库中定义的Result<T, E>的方法：unwrap_or_else。当Result是Ok时其行为类似于unwrap：它返回Ok内部封装的值。与unwrap不同的是，当Result是Err时，它调用一个闭包（closure），也就是一个我们定义的作为参数传递给unwrap_or_else的匿名函数。第十三章会更详细的介绍闭包；这里需要理解的重要部分是unwrap_or_else会将Err的内部值传递给闭包中位于两道竖线间的参数err。使用unwrap_or_else允许我们进行一些自定义的非panic!的错误处理。

-
上述的错误处理其实只有两行：我们打印出了错误，接着调用了std::process::exit。这个函数立刻停止程序的执行并将传递给它的数组作为返回码。依照惯例，零代表成功而任何其他数字表示失败。就结果来说这依然类似于列表 12-7 中的基于panic!的错误处理，但是不再会有额外的输出了，让我们试一试：

+
+
+
+
在上面的列表中，使用了一个之前没有涉及到的方法：unwrap_or_else，它定义于标准库的Result<T, E>上。使用unwrap_or_else可以进行一些自定义的非panic!的错误处理。当Result是Ok时，这个方法的行为类似于unwrap：它返回Ok内部封装的值。然而，当Result是Err时，它调用一个闭包（closure），也就是一个我们定义的作为参数传递给unwrap_or_else的匿名函数。第十三章会更详细的介绍闭包。现在你需要理解的是unwrap_or_else会将Err的内部值，也就是列表 12-9 中增加的not enough arguments静态字符串的情况，传递给闭包中位于两道竖线间的参数err。闭包中的代码在其运行时可以使用这个err值。

+
+
+
我们新增了一个use行来从标准库中导入process。在错误的情况闭包中将被运行的代码只有两行：我们打印出了err值，接着调用了std::process::exit（在开头增加了新的use行从标准库中导入了process）。process::exit会立即停止程序并将传递给它的数字作为返回状态码。这类似于列表 12-8 中使用的基于panic!的错误处理，除了不会在得到所有的额外输出了。让我们试试：

 
$ cargo run
    Compiling greprs v0.1.0 (file:///projects/greprs)
     Finished debug [unoptimized + debuginfo] target(s) in 0.48 secs
-     Running `target\debug\greprs.exe`
+     Running `target/debug/greprs`
 Problem parsing arguments: not enough arguments
 

-
非常好！现在输出就友好多了。

-
run函数中的错误处理

-
现在重构完了参数解析部分，让我们再改进一下程序的逻辑。列表 12-10 中展示了在main函数中调用提取出函数run之后的代码。run函数包含之前位于main中的部分代码：

+
非常好！现在输出对于用户来说就友好多了。

+
提取run函数

+
现在我们完成了配置解析的重构：让我们转向程序的逻辑。正如“二进制项目的关注分离”部分的讨论所留下的过程，我们将提取一个叫做run的函数来存放目前main函数中不属于设置配置或处理错误的所有逻辑。一旦完成这些，main函数将简明的足以通过观察来验证，而我们将能够为所有其他逻辑编写测试。

+
+
+
列表 12-11 展示了提取出来的run函数。目前我们只进行小的增量式的提取函数的改进并仍将在 src/main.rs 中定义这个函数：

 
Filename: src/main.rs

 
fn main() {
     // ...snip...
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     run(config);
@@ -297,10 +364,12 @@ fn run(config: Config) {
 
 // ...snip...
 

-
Listing 12-10: Extracting a run functionality for the
+
Listing 12-11: Extracting a run function containing the
 rest of the program logic

 
-
run函数的内容是之前位于main中的几行，而且run函数获取一个Config作为参数。现在有了一个单独的函数了，我们就可以像列表 12-8 中的Config::new那样进行类似的改进了。列表 12-11 展示了另一个use语句将std::error::Error结构引入了作用域，还有使run函数返回Result的修改：

+
现在run函数包含了main中从读取文件开始的剩余的所有逻辑。run函数获取一个Config实例作为参数。

+
从run函数中返回错误

+
通过将剩余的逻辑分离进run函数而不是留在main中，就可以像列表 12-9 中的Config::new那样改进错误处理。不再通过通过expect允许程序 panic，run函数将会在出错时返回一个Result<T, E>。这让我们进一步以一种对用户友好的方式统一main中的错误处理。列表 12-12 展示了run签名和函数体中的变化：

 
Filename: src/main.rs

 
use std::error::Error;
 
@@ -317,25 +386,31 @@ fn run(config: Config) -> Result<(), Box<Error>> {
     Ok(())
 }
 

-
Listing 12-11: Changing the run function to return
+
Listing 12-12: Changing the run function to return
 Result

 
-
这里有三个大的修改。第一个是现在run函数的返回值是Result<(), Box<Error>>类型的。之前，函数返回 unit 类型()，现在它仍然是Ok时的返回值。对于错误类型，我们将使用Box<Error>。这是一个trait 对象（trait object），第XX章会讲到。现在可以这样理解它：Box<Error>意味着函数返回了某个实现了Error trait 的类型，不过并没有指定具体的返回值类型。这样就比较灵活，因为在不同的错误场景可能有不同类型的错误返回值。Box是一个堆数据的智能指针，第十五章将会详细介绍Box。

-
第二个改变是我们去掉了expect调用并替换为第9章讲到的?。不同于遇到错误就panic!，这会从函数中返回错误值并让调用者来处理它。

-
第三个修改是现在成功时这个函数会返回一个Ok值。因为run函数签名中声明成功类型返回值是()，所以需要将 unit 类型值包装进Ok值中。Ok(())一开始看起来有点奇怪，不过这样使用()是表明我们调用run只是为了它的副作用的惯用方式；它并没有返回什么有意义的值。

+
这里做出了三个大的改变。第一，改变了run函数的返回值为Result<(), Box<Error>>。之前这个函数返回 unit 类型()，现在它仍然保持作为Ok时的返回值。

+
+
+
对于错误类型，使用了trait 对象Box<Error>（在开头使用了use语句将std::error::Error引入作用域）。第十七章会涉及 trait 对象。目前只需知道Box<Error>意味着函数会返回实现了Error trait 的类型，不过无需指定具体将会返回的值的类型。这提供了在不同的错误场景可能有不同类型的错误返回值的灵活性。

+
第二个改变是去掉了expect调用并替换为第九章讲到的?。不同于遇到错误就panic!，这会从函数中返回错误值并让调用者来处理它。

+
第三个修改是现在成功时这个函数会返回一个Ok值。因为run函数签名中声明成功类型返回值是()，这意味着需要将 unit 类型值包装进Ok值中。Ok(())一开始看起来有点奇怪，不过这样使用()是表明我们调用run只是为了它的副作用的惯用方式；它并没有返回什么有意义的值。

 
上述代码能够编译，不过会有一个警告：

 
warning: unused result which must be used, #[warn(unused_must_use)] on by default
-  --> src\main.rs:39:5
+  --> src/main.rs:39:5
    |
 39 |     run(config);
    |     ^^^^^^^^^^^^
 

-
Rust 尝试告诉我们忽略Result，它有可能是一个错误值。让我们现在来处理它。我们将采用类似于列表 12-9 中处理Config::new错误的技巧，不过还有少许不同：

+
Rust 提示我们的代码忽略了Result值，它可能表明这里存在一个错误。虽然我们没有检查这里是否有一个错误，而编译器提醒我们这里应该有一些错误处理代码！现在就让我们修正他们。

+
处理main中run返回的错误

+
我们将检查错误并使用与列表 12-10 中处理错误类似的技术来优雅的处理他们，不过有一些细微的不同：

 
Filename: src/main.rs

 
fn main() {
     // ...snip...
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     if let Err(e) = run(config) {
@@ -344,35 +419,27 @@ fn run(config: Config) -> Result<(), Box<Error>> {
         process::exit(1);
     }
 }
-
-fn run(config: Config) -> Result<(), Box<Error>> {
-    let mut f = File::open(config.filename)?;
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)?;
-
-    println!("With text:\n{}", contents);
-
-    Ok(())
-}
 

 
-
不同于unwrap_or_else，我们使用if let来检查run是否返回Err，如果是则调用process::exit(1)。为什么呢？这个例子和Config::new的区别有些微妙。对于Config::new我们关心两件事：

-
    
-
  1. 检测出任何可能发生的错误
    2. 
-
  2. 如果没有出现错误创建一个Config
    3. 
-

-
而在这个情况下，因为run在成功的时候返回一个()，唯一需要担心的就是第一件事：检测错误。如果我们使用了unwrap_or_else，则会得到()的返回值。它并没有什么用处。

-
虽然两种情况下if let和unwrap_or_else的内容都是一样的：打印出错误并退出。

+
我们使用if let来检查run是否返回一个Err值，不同于unwrap_or_else，并在出错时调用process::exit(1)。run并不返回像Config::new返回的Config实例那样需要unwrap的值。因为run在成功时返回()，而我们只关心发现一个错误，所以并不需要unwrap_or_else来返回未封装的值，因为它只会是()。

+
不过两个例子中if let和unwrap_or_else的函数体都一样：打印出错误并退出。

 
将代码拆分到库 crate

-
现在项目看起来好多了！还有一件我们尚未开始的工作：拆分 src/main.rs 并将一些代码放入 src/lib.rs 中。让我们现在就开始吧：将 src/main.rs 中的run函数移动到新建的 src/lib.rs 中。还需要移动相关的use语句和Config的定义，以及其new方法。现在 src/lib.rs 应该如列表 12-12 所示：

+
现在项目看起来好多了！现在我们将要拆分 src/main.rs 并将一些代码放入 src/lib.rs，这样就能测试他们并拥有一个小的main函数。

+
让我们将如下代码片段从 src/main.rs 移动到新文件 src/lib.rs 中：

+
    
+
  • run函数定义
    • 
+
  • 相关的use语句
    • 
+
  • Config的定义
    • 
+
  • Config::new函数定义
    • 
+

+
现在 src/lib.rs 的内容应该看起来像列表 12-13：

 
Filename: src/lib.rs

 
use std::error::Error;
 use std::fs::File;
 use std::io::prelude::*;
 
 pub struct Config {
-    pub search: String,
+    pub query: String,
     pub filename: String,
 }
 
@@ -382,11 +449,11 @@ impl Config {
             return Err("not enough arguments");
         }
 
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Ok(Config {
-            search: search,
+            query: query,
             filename: filename,
         })
     }
@@ -403,11 +470,12 @@ pub fn run(config: Config) -> Result<(), Box<Error>>{
     Ok(())
 }
 

-
Listing 12-12: Moving Config and run into
+
Listing 12-13: Moving Config and run into
 src/lib.rs

 
-注意我们还需要使用公有的`pub`：在`Config`和其字段、它的`new`方法和`run`函数上。
-
现在在 src/main.rs 中，我们需要通过extern crate greprs来引入现在位于 src/lib.rs 的代码。接着需要增加一行use greprs::Config来引入Config到作用域，并对run函数加上 crate 名称前缀，如列表 12-13 所示：

+
这里使用了公有的pub：在Config、其字段和其new方法，以及run函数上。现在我们有了一个拥有可以测试的公有 API 的库 crate 了。

+
从二进制 crate 中调用库 crate

+
现在需要在 src/main.rs 中使用extern crate greprs将移动到 src/lib.rs 的代码引入二进制 crate 的作用域。接着我们将增加一个use greprs::Config行将Config类型引入作用域，并使用库 crate 的名称作为run函数的前缀，如列表 12-14 所示：

 
Filename: src/main.rs

 
extern crate greprs;
 
@@ -424,7 +492,7 @@ fn main() {
         process::exit(1);
     });
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     if let Err(e) = greprs::run(config) {
@@ -434,12 +502,17 @@ fn main() {
     }
 }
 

-
Listing 12-13: Bringing the greprs crate into the scope
+
Listing 12-14: Bringing the greprs crate into the scope
 of src/main.rs

 
-
-
通过这些重构，所有代码应该都能运行了。运行几次cargo run来确保你没有破坏什么内容。好的！确实有很多的内容，不过已经为将来的成功奠定了基础。我们采用了一种更加优秀的方式来处理错误，并使得代码更模块化了一些。从现在开始几乎所有的工作都将在 src/lib.rs 中进行。

-
让我们利用这新创建的模块的优势来进行一些在旧代码中难以开开展的工作，他们在新代码中却很简单：编写测试！

+
通过这些重构，所有功能应该抖联系在一起并可以运行了。运行cargo run来确保一切都正确的衔接在一起。

+
+
+
哇哦！这可有很多的工作，不过我们为将来成功打下了基础。现在处理错误将更容易，同时代码也更模块化。从现在开始几乎所有的工作都将在 src/lib.rs 中进行。

+
让我们利用这些新创建的模块的优势来进行一些在旧代码中难以展开的工作，他们在新代码中却很简单：编写测试！

 
                 

 
diff --git a/docs/ch17-01-what-is-oo.html b/docs/ch17-01-what-is-oo.html
index 10c3dd1..7efdbff 100644
--- a/docs/ch17-01-what-is-oo.html
+++ b/docs/ch17-01-what-is-oo.html
@@ -124,6 +124,21 @@ impl AveragedCollection {
 }

Listing 17-2:在AveragedCollection结构体上实现了add、remove和average public方法

+

public方法add、remove和average是修改AveragedCollection实例的唯一方式。当使用add方法把一个元素加入到list或者使用remove方法来删除它，这些方法的实现同时会调用私有的update_average方法来更新average成员变量。因为list和average是私有的，没有其他方式来使得外部的代码直接向list增加或者删除元素，直接操作list可能会引发average字段不同步。average方法返回average字段的值，这指的外部的代码只能读取average而不能修改它。

+

因为我们已经封装好了AveragedCollection的实现细节，所以我们也可以像使用list一样使用的一个不同的数据结构，比如用HashSet代替Vec。只要签名add、remove和average公有函数保持相同，使用AveragedCollection的代码无需改变。如果我们暴露List给外部代码时，未必都是这样，因为HashSet和Vec使用不同的函数增加元素，所以如果要想直接修改list的话，外部的代码可能还得修改。

+

如果封装是一个语言被认为是面向对象语言必要的方面的话，那么Rust满足要求。在代码中不同的部分使用或者不使用pub决定了实现细节的封装。

+

作为类型系统的继承和作为代码共享的继承

 +

继承是一个很多编程语言都提供的机制，一个对象可以从另外一个对象的定义继承，这使得可以获得父对象的数据和行为，而不用重新定义。很多人定义面向对象语言时，认为继承是一个特色。

+

如果一个语言必须有继承才能被称为面向对象的语言，那么Rust就不是面向对象的。没有办法定义一个结构体继承自另外一个结构体，从而获得父结构体的成员和方法。然而，如果你过去常常在你的编程工具箱使用继承，依赖于你要使用继承的原因，在Rust中有其他的方式。

+

使用继承有两个主要的原因。第一个是为了重用代码：一旦一个特殊的行为从一个类型继承，继承可以在另外一个类型实现代码重用。Rust代码可以被共享通过使用默认的trait方法实现，可以在Listing 10-14看到，我们增加一个summary方法到Summarizabletrait。任何继承了Summarizabletrait的类型上会有summary方法，而无需任何的父代码。这类似于父类有一个继承的方法，一个从父类继承的子类也因为继承有了继承的方法。当实现Summarizabletrait时，我们也可以选择覆写默认的summary方法，这类似于子类覆写了从父类继承的实现方法。

+

第二个使用继承的原因是，使用类型系统：子类型可以在父类型被使用的地方使用。这也称为多态，意味着如果多种对象有一个相同的shape，它们可以被其他替代。

+
+

虽然很多人使用多态来描述继承，但是它实际上是一种特殊的多态，称为子类型多态。也有很多种其他形式，在Rust中带有通用的ttait绑定的一个参数 +也是多态——更特殊的类型多态。在多种类型的多态间的细节不是关键的，所以不要过于担心细节，只需要知道Rust有多种多态相关的特色就好，不像很多其他OOP语言。

+
+

为了支持这种样式，Rust有trait对象，这样我们可以指定给任何类型的值，只要值实现了一种特定的trait。

+

继承最近在很多编程语言的设计方案中失宠了。使用继承类实现代码重用需要共享比你需要共享的代码。子类不应该经常共享它们的父类的所有特色，但是继承意味着子类得到了它的父类的数据和行为。这使得一个程序的设计不灵活，创建了无意义的子类的方法被调用的可能性或者由于方法不适用于子类但是必须从父类继承，从而触发错误。另外，很多语言只允许从一个类继承，更加限制了程序设计的灵活性。

+

因为这些原因，Rust选择了一个另外的途径，使用trait替代继承。让我们看一下在Rust中trait对象是如何实现多态的。

diff --git a/docs/print.html b/docs/print.html index c0d834e..2275a73 100644 --- a/docs/print.html +++ b/docs/print.html @@ -2375,7 +2375,7 @@ fn area(rectangle: &Rectangle) -> u32 {

这里我们定义了一个结构体并称其为Rectangle。在{}中定义了字段length和width，都是u32类型的。接着在main中，我们创建了一个长度为 50 和宽度为 30 的Rectangle的具体实例。

函数area现在被定义为接收一个名叫rectangle的参数，它的类型是一个结构体Rectangle实例的不可变借用。第四章讲到过，我们希望借用结构体而不是获取它的所有权这样main函数就可以保持rect1的所有权并继续使用它，所以这就是为什么在函数签名和调用的地方会有&。

-

area函数访问Rectangle的length和width字段。area的签名现在明确的表明了我们的意图：通过其length和width字段，计算一个Rectangle的面积，。这表明了长度和宽度是相互联系的，并为这些值提供了描述性的名称而不是使用元组的索引值0和1。这是明确性的胜利。

+

area函数访问Rectangle的length和width字段。area的签名现在明确的表明了我们的意图：通过其length和width字段，计算一个Rectangle的面积，。这表明了长度和宽度是相互联系的，并为这些值提供了描述性的名称而不是使用元组的索引值0和1。结构体胜在更清晰明了。

通过衍生 trait 增加实用功能

如果能够在调试程序时打印出Rectangle实例来查看其所有字段的值就更好了。列表 5-5 尝试像往常一样使用println!宏：

Filename: src/main.rs

@@ -2470,7 +2470,7 @@ struct

为了使函数定义于Rectangle的上下文中，我们开始了一个impl块（impl是 implementation 的缩写）。接着将函数移动到impl大括号中，并将签名中的第一个（在这里也是唯一一个）参数和函数体中其他地方的对应参数改成self。然后在main中将我们调用area方法并传递rect1作为参数的地方，改成使用方法语法在Rectangle实例上调用area方法。方法语法获取一个实例并加上一个点号后跟方法名、括号以及任何参数。

在area的签名中，开始使用&self来替代rectangle: &Rectangle，因为该方法位于impl Rectangle 上下文中所以 Rust 知道self的类型是Rectangle。注意仍然需要在self前面加上&，就像&Rectangle一样。方法可以选择获取self的所有权，像我们这里一样不可变的借用self，或者可变的借用self，就跟其他别的参数一样。

-

这里选择&self跟在函数版本中使用&Rectangle出于同样的理由：我们并不想获取所有权，只希望能够读取结构体中的数据，而不是写入。如果想要能够在方法中改变调用方法的实例的话，需要将抵押给参数改为&mut self。通过仅仅使用self作为第一个参数来使方法获取实例的所有权，不过这是很少见的；这通常用在当方法将self转换成别的实例的时候，同时我们想要防止调用者在转换之后使用原始的实例。

+

这里选择&self跟在函数版本中使用&Rectangle出于同样的理由：我们并不想获取所有权，只希望能够读取结构体中的数据，而不是写入。如果想要能够在方法中改变调用方法的实例的话，需要将第一个参数改为&mut self。通过仅仅使用self作为第一个参数来使方法获取实例的所有权，不过这是很少见的；这通常用在当方法将self转换成别的实例的时候，同时我们想要防止调用者在转换之后使用原始的实例。

使用方法而不是函数，除了使用了方法语法和不需要在每个函数签名中重复self类型外，其主要好处在于组织性。我将某个类型实例能做的所有事情都一起放入impl块中，而不是让将来的用户在我们的代码中到处寻找Rectangle的功能。

@@ -2497,7 +2497,7 @@ struct

p1.distance(&p2); (&p1).distance(&p2); -

第一行看起来简洁的多。这种自动引用的行为之所以能行得通是因为方法有一个明确的接收者————self的类型。在给出接收者和方法名的前提下，Rust 可以明确的计算出方法是仅仅读取（所以需要&self），做出修改（所以是&mut self）或者是获取所有权（所以是self）。Rust 这种使得借用对方法接收者来说是隐式的做法是其所有权系统人体工程学实践的一大部分。

+

第一行看起来简洁的多。这种自动引用的行为之所以能行得通是因为方法有一个明确的接收者————self的类型。在给出接收者和方法名的前提下，Rust 可以明确的计算出方法是仅仅读取（所以需要&self），做出修改（所以是&mut self）或者是获取所有权（所以是self）。Rust 这种使得借用对方法接收者来说是隐式的做法是其所有权系统程序员友好性实现的一大部分。

带有更多参数的方法

 @@ -2657,7 +2657,7 @@ let home = IpAddr::V4(127, 0, 0, 1); let loopback = IpAddr::V6(String::from("::1")); -

这些代码展示了使用枚举来储存两种不同 IP 地址的几种可能的选择。然而，事实证明储存和编码 IP 地址实在是太常见了以致标准库提供了一个可供使用的定义！让我们看看标准库如何定义IpAddr的：它正有着跟我们定义和使用的一样的枚举和成员，不过它将成员种的地址数据嵌入到了两个不同形式的结构体中，他们对不同的成员的定义是不同的：

+

这些代码展示了使用枚举来储存两种不同 IP 地址的几种可能的选择。然而，事实证明储存和编码 IP 地址实在是太常见了以致标准库提供了一个可供使用的定义！让我们看看标准库如何定义IpAddr的：它正有着跟我们定义和使用的一样的枚举和成员，不过它将成员中的地址数据嵌入到了两个不同形式的结构体中，他们对不同的成员的定义是不同的：

struct Ipv4Addr {
     // details elided
 }
@@ -6460,7 +6460,7 @@ To tell your name the livelong day
 To an admiring bog!

好的！代码读取并打印出了文件的内容。虽然它还有一些瑕疵：main函数有着多个功能，同时也没有处理可能出现的错误。虽然我们的程序还很小，这些瑕疵并不是什么大问题。不过随着程序功能的丰富，将会越来越难以用简单的方法修复他们。在开发程序时，及早开始重构是一个最佳实践，因为重构少量代码时要容易的多，所以让我们现在就开始吧。

-

读取文件

 +

重构改进模块性和错误处理

ch12-03-improving-error-handling-and-modularity.md
@@ -6473,57 +6473,73 @@ commit b8e4fcbf289b82c12121b282747ce05180afb1fb

第四，我们不停的使用expect来处理不同的错误，如果用户没有指定足够的参数来运行程序，他们会从 Rust 得到 "index out of bounds" 错误而这并不能明确的解释问题。如果所有的错误处理都位于一处这样将来的维护者在需要修改错误处理逻辑时就只需要咨询一处代码。将所有的错误处理都放在一处也有助于确保我们打印的错误信息对终端用户来说是有意义的。

让我们通过重构项目来解决这些问题。

二进制项目的关注分离

 -

这类项目组织上的问题在很多相似类型的项目中很常见，所以 Rust 社区开发出一种关注分离的组织模式。这种模式可以用来组织任何用 Rust 构建的二进制项目，所以可以证明应该更早的开始这项重构，以为我们的项目符合这个模式。这个模式看起来像这样：

+

main函数负责多个任务的组织问题在许多二进制项目中很常见。所以 Rust 社区开发出一个类在main函数开始变得庞大时进行二进制程序的关注分离的指导性过程。这些过程有如下步骤：

    -
  1. 将程序拆分成 main.rs 和 lib.rs。
    2. -
  2. 将命令行参数解析逻辑放入 main.rs。
    3. -
  3. 将程序逻辑放入 lib.rs。
    4. -
  4. main函数的工作是： +
  5. 将程序拆分成 main.rs 和 lib.rs 并将程序的逻辑放入 lib.rs 中。
    6. +
  6. 当命令行解析逻辑比较小时，可以保留在 main.rs 中。
    7. +
  7. 当命令行解析开始变得复杂时，也同样将其从 main.rs 提取到 lib.rs中。
    8. +
  8. 经过这些过程之后保留在main函数中的责任是：
      -
    • 解析参数
      • -
    • 设置所有配置性变量
      • +
    • 使用参数值调用命令行解析逻辑
      • +
    • 设置任何其他的配置
    • 调用 lib.rs 中的run函数
      • -
    • 如果run返回错误则处理这个错误
      • +
    • 如果run返回错误，则处理这个错误
-

好的！老实说这个模式好像还很复杂。这就是关注分离的所有内容：main.rs 负责实际的程序运行，而 lib.rs 处理所有真正的任务逻辑。让我们将程序重构成这种模式。首先，提取出一个目的只在于解析参数的函数。列表 12-4 中展示了一个新的开始，main函数调用了一个新函数parse_config，它仍然定义于 src/main.rs 中：

+

这个模式的一切就是为了关注分离：main.rs 处理程序运行，而 lib.rs 处理所有的真正的任务逻辑。因为不能直接测试main函数，这个结构通过将所有的程序逻辑移动到 lib.rs 的函数中使得我们可以测试他们。仅仅保留在 main.rs 中的代码将足够小以便阅读就可以验证其正确性。

+ + +

提取参数解析器

 +

首先，我们将提取解析参数的功能。列表 12-5 中展示了新main函数的开头，它调用了新函数parse_config。目前它仍将定义在 src/main.rs 中：

Filename: src/main.rs

fn main() {
     let args: Vec<String> = env::args().collect();
 
-    let (search, filename) = parse_config(&args);
-
-    println!("Searching for {}", search);
-    println!("In file {}", filename);
+    let (query, filename) = parse_config(&args);
 
     // ...snip...
 }
 
 fn parse_config(args: &[String]) -> (&str, &str) {
-    let search = &args[1];
+    let query = &args[1];
     let filename = &args[2];
 
-    (search, filename)
+    (query, filename)
 }
-

Listing 12-4: Extract a parse_config function from +

Listing 12-5: Extract a parse_config function from main

-

这看起来好像有点复杂，不过我们将一点一点的开展重构。在做出这些改变之后，再次运行程序并验证参数解析是否仍然正常。经常验证你的进展是一个好习惯，这样在遇到问题时就能更好地理解什么修改造成了错误。

+

我们仍然将命令行参数收集进一个 vector，不过不同于在main函数中将索引 1 的参数值赋值给变量query和将索引 2 的值赋值给变量filename，我们将整个 vector 传递给parse_config函数。接着parse_config函数将包含知道哪个参数该放入哪个变量的逻辑，并将这些值返回到main。仍然在main中创建变量query和filename，不过main不再负责处理命令行参数与变量如何对应。

+

这对我们这小程序可能有点大材小用，不过我们将采用小的、增量的步骤进行重构。在做出这些改变之后，再次运行程序并验证参数解析是否仍然正常。经常验证你的进展是一个好习惯，这样在遇到问题时能帮助你定位问题的成因。

组合配置值

 -

现在我们有了一个函数了，让我们接着完善它。我们代码还能设计的更好一些：函数返回了一个元组，不过接着立刻就解构成了单独的部分。这些代码本身没有问题，不过有一个地方表明仍有改善的余地：我们调用了parse_config方法。函数名中的config部分也表明了返回的两个值应该是组合在一起的，因为他们都是某个配置值的一部分。

+

我们可以采取另一个小的步骤来进一步改善这个函数。现在函数返回一个元组，不过立刻又就将元组拆成了独立的部分。这是一个我们可能没有进行正确抽象的信号。

+

另一个表明还有改进空间的迹象是parse_config的config部分，它暗示了我们返回的两个值是相关的并都是一个配置值的一部分。目前除了将这两个值组合进元组之外并没有表达这个数据结构的意义：我们可以将这两个值放入一个结构体并给每个字段一个有意义的名字。这会让未来的维护者更容易理解不同的值如何相互关联以及他们的目的。

+
-

注意：一些同学将当使用符合类型更为合适的时候使用基本类型当作一种称为基本类型偏执（primitive obsession）的反模式。

+

注意：一些同学将这种当使用符合类型更为合适的时候使用基本类型的反模式称为基本类型偏执（primitive obsession）。

-

让我们引入一个结构体来存放所有的配置。列表 12-5 中展示了新增的Config结构体定义、重构后的parse_config和main函数中的相关更新：

-

Filename: src/main.rs

-
fn main() {
+
+
+
列表 12-6 展示了新定义的结构体Config，它有字段query和filename。我们也改变了parse_config函数来返回一个Config结构体的实例，并更新main来使用结构体字段而不是单独的变量：

+
Filename: src/main.rs

+
# use std::env;
+# use std::fs::File;
+#
+fn main() {
     let args: Vec<String> = env::args().collect();
 
     let config = parse_config(&args);
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     let mut f = File::open(config.filename).expect("file not found");
@@ -6532,88 +6548,121 @@ fn parse_config(args: &[String]) -> (&str, &str) {
 }
 
 struct Config {
-    search: String,
+    query: String,
     filename: String,
 }
 
 fn parse_config(args: &[String]) -> Config {
-    let search = args[1].clone();
+    let query = args[1].clone();
     let filename = args[2].clone();
 
     Config {
-        search: search,
+        query: query,
         filename: filename,
     }
 }
 

-
Listing 12-5: Refactoring parse_config to return an
-instance of a Config struct

+
Listing 12-6: Refactoring parse_config to return an instance of a Config
+struct

 
-
parse_config的签名现在表明它返回一个Config值。在parse_config的函数体中，我们之前返回了args中String值引用的字符串 slice，不过Config定义为拥有两个有所有权的String值。因为parse_config的参数是一个String值的 slice，Config实例不能获取String值的所有权：这违反了 Rust 的借用规则，因为main函数中的args变量拥有这些String值并只允许parse_config函数借用他们。

-
还有许多不同的方式可以处理String的数据；现在我们使用简单但低效率的方式，在字符串 slice 上调用clone方法。clone调用会生成一个字符串数据的完整拷贝，而且Config实例可以拥有它，不过这会消耗更多时间和内存来储存拷贝字符串数据的引用，不过拷贝数据让我们使我们的代码显得更加直白。

+
parse_config的签名现在表明它返回一个Config值。在parse_config的函数体中，之前返回了args中String值引用的字符串 slice，现在我们选择定义Config来使用拥有所有权的String值。main中的args变量是参数值的所有者并只允许parse_config函数借用他们，这意味着如果Config尝试获取args中值的所有权将违反 Rust 的借用规则。

+
还有许多不同的方式可以处理String的数据，而最简单但有些不太高效的方式是调用这些值的clone方法。这会生成Config实例可以拥有的数据的完整拷贝，不过会比储存字符串数据的引用消耗更多的时间和内存。不过拷贝数据使得代码显得更加直白因为无需管理引用的生命周期，所以在这种情况下牺牲一小部分性能来换取简洁性的取舍是值得的。

 
 

 
使用clone权衡取舍

-
由于其运行时消耗，许多 Rustacean 之间有一个趋势是倾向于不使用clone来解决所有权问题。在关于迭代器的第十三章中，我们将会学习如何更有效率的处理这种情况。现在，为了编写我们的程序拷贝一些字符串是没有问题。我们只进行了一次拷贝，而且文件名和要搜索的字符串都比较短。随着你对 Rust 更加熟练，将更轻松的省略这个权衡的步骤，不过现在调用clone是完全可以接受的。

+
由于其运行时消耗，许多 Rustacean 之间有一个趋势是倾向于避免使用clone来解决所有权问题。在关于迭代器的第十三章中，我们将会学习如何更有效率的处理这种情况，不过现在，复制一些字符串来取得进展是没有问题的，因为只会进行一次这样的拷贝，而且文件名和要搜索的字符串都比较短。在第一轮编写时拥有一个可以工作但有点低效的程序要比尝试过度优化代码更好一些。随着你对 Rust 更加熟练，将能更轻松的直奔合适的方法，不过现在调用clone是完全可以接受的。

 

 
-
main函数更新为将parse_config返回的Config实例放入变量config中，并将分别使用search和filename变量的代码更新为使用Config结构体的字段。

+
我们更新main将parse_config返回的Config实例放入变量config中，并更新之前分别使用search和filename变量的代码为现在的使用Config结构体的字段。

+
现在代码更明确的表现了我们的意图，query和filename是相关联的并且他们的目的是配置程序如何工作的。任何使用这些值的代码就知道在config实例中对应目的的字段名中寻找他们。

 
创建一个Config构造函数

-
现在让我们考虑一下parse_config的目的：这是一个创建Config示例的函数。我们已经见过了一个创建实例函数的规范：像String::new这样的new函数。列表 12-6 中展示了将parse_config转换为一个Config结构体关联函数new的代码：

-
Filename: src/main.rs

-
fn main() {
+
+
+
目前为止，我们将负责解析命令行参数的逻辑从main提取到了parse_config函数中，这帮助我们看清值query和filename是相互关联的并应该在代码中表现这种关系。接着我们增加了Config结构体来命名query和filename的相关目的，并能够从parse_config函数中将这些值的名称作为结构体字段名称返回。

+
所以现在parse_config函数的目的是创建一个Config实例，我们可以将parse_config从一个普通函数变为一个叫做new的与结构体关联的函数。做出这个改变使得代码更符合习惯：可以像标准库中的String调用String::new来创建一个该类型的实例那样，将parse_config变为一个与Config关联的new函数。列表 12-7 展示了需要做出的修改：

+
Filename: src/main.rs

+
# use std::env;
+#
+fn main() {
     let args: Vec<String> = env::args().collect();
 
     let config = Config::new(&args);
 
-    println!("Searching for {}", config.search);
-    println!("In file {}", config.filename);
-
     // ...snip...
 }
 
+# struct Config {
+#     query: String,
+#     filename: String,
+# }
+#
 // ...snip...
 
 impl Config {
     fn new(args: &[String]) -> Config {
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Config {
-            search: search,
+            query: query,
             filename: filename,
         }
     }
 }
 

-
Listing 12-6: Changing parse_config into
+
Listing 12-7: Changing parse_config into
 Config::new

 
-
我们将parse_config的名字改为new并将其移动到impl块中。我们也更新了main中的调用代码。再次尝试编译并确保程序可以运行。

-
从构造函数返回Result

-
这是我们对这个方法最后的重构：还记得当 vector 含有少于三个项时访问索引 1 和 2 会 panic 并给出一个糟糕的错误信息的代码吗？让我们来修改它！列表 12-7 展示了如何在访问这些位置之前检查 slice 是否足够长，并使用一个更好的 panic 信息：

+
这里将main中调用parse_config的地方更新为调用Config::new。我们将parse_config的名字改为new并将其移动到impl块中，这使得new函数与Config相关联。再次尝试编译并确保它可以工作。

+
修复错误处理

+
现在我们开始修复错误处理。回忆一下之前提到过如果args vector 包含少于 3 个项并尝试访问 vector 中索引 1 或 索引 2 的值会造成程序 panic。尝试不带任何参数运行程序；这将看起来像这样：

+
$ cargo run
+    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
+     Running `target/debug/greprs`
+thread 'main' panicked at 'index out of bounds: the len is 1
+but the index is 1',  /stable-dist-rustc/build/src/libcollections/vec.rs:1307
+note: Run with `RUST_BACKTRACE=1` for a backtrace.
+

+
index out of bounds: the len is 1 but the index is 1是一个针对程序员的错误信息，这并不能真正帮助终端用户理解发生了什么和相反他们应该做什么。现在就让我们修复它吧。

+
改善错误信息

+
在列表 12-8 中，在new函数中增加了一个检查在访问索引 1 和 2 之前检查 slice 是否足够长。如果 slice 不够长，我们使用一个更好的错误信息 panic 而不是index out of bounds信息：

 
Filename: src/main.rs

 
// ...snip...
 fn new(args: &[String]) -> Config {
     if args.len() < 3 {
         panic!("not enough arguments");
     }
-
-    let search = args[1].clone();
     // ...snip...
-}
 

-
Listing 12-7: Adding a check for the number of
+
Listing 12-8: Adding a check for the number of
 arguments

 
-
通过在new中添加这额外的几行代码，再次尝试不带参数运行程序：

+
这类似于列表 9-8 中的Guess::new函数，那里如果value参数超出了有效值的范围就调用panic!。不同于检查值的范围，这里检查args的长度至少是 3，而函数的剩余部分则可以假设这个条件成立的基础上运行。如果
+args少于 3 个项，这个条件将为真，并调用panic!立即终止程序。

+
有了new中这几行额外的代码，再次不带任何参数运行程序并看看现在错误看起来像什么：

 
$ cargo run
     Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target\debug\greprs.exe`
-thread 'main' panicked at 'not enough arguments', src\main.rs:29
+     Running `target/debug/greprs`
+thread 'main' panicked at 'not enough arguments', src/main.rs:29
 note: Run with `RUST_BACKTRACE=1` for a backtrace.
 

-
这样就好多了！至少有个一个符合常理的错误信息。然而，还有一堆额外的信息我们并不希望提供给用户。可以通过改变new的签名来完善它。现在它只返回了一个Config，所有没有办法表示创建Config失败的情况。相反，可以如列表 12-8 所示返回一个Result：

+
这个输出就好多了，现在有了一个合理的错误信息。然而，我们还有一堆额外的信息不希望提供给用户。所以在这里使用列表 9-8 中的技术可能不是最好的；无论如何panic!调用更适合程序问题而不是使用问题，正如第九章所讲到的。相反我们可以使用那一章学习的另一个技术：返回一个可以表明成功或错误的Result。

+
+
+
从new中返回Result而不是调用panic!

+
我们可以选择返回一个Result值，它在成功时会包含一个Config的实例，而在错误时会描述问题。当Config::new与main交流时，在使用Result类型存在问题时可以使用 Rust 的信号方式。接着修改main将Err成员转换为对用户更友好的错误，而不是panic!调用产生的关于thread 'main'和RUST_BACKTRACE的文本。

+
列表 12-9 展示了Config::new返回值和函数体中返回Result所需的改变：

 
Filename: src/main.rs

 
impl Config {
     fn new(args: &[String]) -> Result<Config, &'static str> {
@@ -6621,25 +6670,28 @@ note: Run with `RUST_BACKTRACE=1` for a backtrace.
             return Err("not enough arguments");
         }
 
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Ok(Config {
-            search: search,
+            query: query,
             filename: filename,
         })
     }
 }
 

-
Listing 12-8: Return a Result from Config::new

+
Listing 12-9: Return a Result from Config::new

 
-
现在new函数返回一个Result，在成功时带有一个Config实例而在出现错误时带有一个&'static str。回忆一下第十章“静态声明周期”中讲到&'static str是一个字符串字面值，他也是现在我们的错误信息。

+
+
+
现在new函数返回一个Result，在成功时带有一个Config实例而在出现错误时带有一个&'static str。回忆一下第十章“静态声明周期”中讲到&'static str是一个字符串字面值，也是目前的错误信息。

 
new函数体中有两处修改：当没有足够参数时不再调用panic!，而是返回Err值。同时我们将Config返回值包装进Ok成员中。这些修改使得函数符合其新的类型签名。

-
Config::new调用和错误处理

-
现在我们需要对main做一些修改，如列表 12-9 所示：

+
通过让Config::new返回一个Err值，这就允许main函数处理new函数返回的Result值并在出现错误的情况更明确的结束进程。

+
Config::new调用并处理错误

+
为了处理错误情况并打印一个对用户友好的信息，我们需要像列表 12-10 那样更新main函数来处理现在Config::new返回的Result。另外还需要实现一些panic!替我们处理的问题：使用错误码 1 退出命令行工具。非零的退出状态是一个告诉调用程序的进程我们的程序以错误状态退出的惯例信号。

 
Filename: src/main.rs

-
// ...snip...
-use std::process;
+
use std::process;
 
 fn main() {
     let args: Vec<String> = env::args().collect();
@@ -6649,31 +6701,46 @@ fn main() {
         process::exit(1);
     });
 
-    println!("Searching for {}", config.search);
-    println!("In file {}", config.filename);
-
     // ...snip...
 

-
Listing 12-9: Exiting with an error code if creating a
+
Listing 12-10: Exiting with an error code if creating a
 new Config fails

 
-
新增了一个use行来从标准库中导入process。在main函数中我们将处理new函数返回的Result值，并在其返回Config::new时以一种更加清楚的方式结束进程。

-
这里使用了一个之前没有讲到的标准库中定义的Result<T, E>的方法：unwrap_or_else。当Result是Ok时其行为类似于unwrap：它返回Ok内部封装的值。与unwrap不同的是，当Result是Err时，它调用一个闭包（closure），也就是一个我们定义的作为参数传递给unwrap_or_else的匿名函数。第十三章会更详细的介绍闭包；这里需要理解的重要部分是unwrap_or_else会将Err的内部值传递给闭包中位于两道竖线间的参数err。使用unwrap_or_else允许我们进行一些自定义的非panic!的错误处理。

-
上述的错误处理其实只有两行：我们打印出了错误，接着调用了std::process::exit。这个函数立刻停止程序的执行并将传递给它的数组作为返回码。依照惯例，零代表成功而任何其他数字表示失败。就结果来说这依然类似于列表 12-7 中的基于panic!的错误处理，但是不再会有额外的输出了，让我们试一试：

+
+
+
+
在上面的列表中，使用了一个之前没有涉及到的方法：unwrap_or_else，它定义于标准库的Result<T, E>上。使用unwrap_or_else可以进行一些自定义的非panic!的错误处理。当Result是Ok时，这个方法的行为类似于unwrap：它返回Ok内部封装的值。然而，当Result是Err时，它调用一个闭包（closure），也就是一个我们定义的作为参数传递给unwrap_or_else的匿名函数。第十三章会更详细的介绍闭包。现在你需要理解的是unwrap_or_else会将Err的内部值，也就是列表 12-9 中增加的not enough arguments静态字符串的情况，传递给闭包中位于两道竖线间的参数err。闭包中的代码在其运行时可以使用这个err值。

+
+
+
我们新增了一个use行来从标准库中导入process。在错误的情况闭包中将被运行的代码只有两行：我们打印出了err值，接着调用了std::process::exit（在开头增加了新的use行从标准库中导入了process）。process::exit会立即停止程序并将传递给它的数字作为返回状态码。这类似于列表 12-8 中使用的基于panic!的错误处理，除了不会在得到所有的额外输出了。让我们试试：

 
$ cargo run
    Compiling greprs v0.1.0 (file:///projects/greprs)
     Finished debug [unoptimized + debuginfo] target(s) in 0.48 secs
-     Running `target\debug\greprs.exe`
+     Running `target/debug/greprs`
 Problem parsing arguments: not enough arguments
 

-
非常好！现在输出就友好多了。

-
run函数中的错误处理

-
现在重构完了参数解析部分，让我们再改进一下程序的逻辑。列表 12-10 中展示了在main函数中调用提取出函数run之后的代码。run函数包含之前位于main中的部分代码：

+
非常好！现在输出对于用户来说就友好多了。

+
提取run函数

+
现在我们完成了配置解析的重构：让我们转向程序的逻辑。正如“二进制项目的关注分离”部分的讨论所留下的过程，我们将提取一个叫做run的函数来存放目前main函数中不属于设置配置或处理错误的所有逻辑。一旦完成这些，main函数将简明的足以通过观察来验证，而我们将能够为所有其他逻辑编写测试。

+
+
+
列表 12-11 展示了提取出来的run函数。目前我们只进行小的增量式的提取函数的改进并仍将在 src/main.rs 中定义这个函数：

 
Filename: src/main.rs

 
fn main() {
     // ...snip...
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     run(config);
@@ -6690,10 +6757,12 @@ fn run(config: Config) {
 
 // ...snip...
 

-
Listing 12-10: Extracting a run functionality for the
+
Listing 12-11: Extracting a run function containing the
 rest of the program logic

 
-
run函数的内容是之前位于main中的几行，而且run函数获取一个Config作为参数。现在有了一个单独的函数了，我们就可以像列表 12-8 中的Config::new那样进行类似的改进了。列表 12-11 展示了另一个use语句将std::error::Error结构引入了作用域，还有使run函数返回Result的修改：

+
现在run函数包含了main中从读取文件开始的剩余的所有逻辑。run函数获取一个Config实例作为参数。

+
从run函数中返回错误

+
通过将剩余的逻辑分离进run函数而不是留在main中，就可以像列表 12-9 中的Config::new那样改进错误处理。不再通过通过expect允许程序 panic，run函数将会在出错时返回一个Result<T, E>。这让我们进一步以一种对用户友好的方式统一main中的错误处理。列表 12-12 展示了run签名和函数体中的变化：

 
Filename: src/main.rs

 
use std::error::Error;
 
@@ -6710,25 +6779,31 @@ fn run(config: Config) -> Result<(), Box<Error>> {
     Ok(())
 }
 

-
Listing 12-11: Changing the run function to return
+
Listing 12-12: Changing the run function to return
 Result

 
-
这里有三个大的修改。第一个是现在run函数的返回值是Result<(), Box<Error>>类型的。之前，函数返回 unit 类型()，现在它仍然是Ok时的返回值。对于错误类型，我们将使用Box<Error>。这是一个trait 对象（trait object），第XX章会讲到。现在可以这样理解它：Box<Error>意味着函数返回了某个实现了Error trait 的类型，不过并没有指定具体的返回值类型。这样就比较灵活，因为在不同的错误场景可能有不同类型的错误返回值。Box是一个堆数据的智能指针，第十五章将会详细介绍Box。

-
第二个改变是我们去掉了expect调用并替换为第9章讲到的?。不同于遇到错误就panic!，这会从函数中返回错误值并让调用者来处理它。

-
第三个修改是现在成功时这个函数会返回一个Ok值。因为run函数签名中声明成功类型返回值是()，所以需要将 unit 类型值包装进Ok值中。Ok(())一开始看起来有点奇怪，不过这样使用()是表明我们调用run只是为了它的副作用的惯用方式；它并没有返回什么有意义的值。

+
这里做出了三个大的改变。第一，改变了run函数的返回值为Result<(), Box<Error>>。之前这个函数返回 unit 类型()，现在它仍然保持作为Ok时的返回值。

+
+
+
对于错误类型，使用了trait 对象Box<Error>（在开头使用了use语句将std::error::Error引入作用域）。第十七章会涉及 trait 对象。目前只需知道Box<Error>意味着函数会返回实现了Error trait 的类型，不过无需指定具体将会返回的值的类型。这提供了在不同的错误场景可能有不同类型的错误返回值的灵活性。

+
第二个改变是去掉了expect调用并替换为第九章讲到的?。不同于遇到错误就panic!，这会从函数中返回错误值并让调用者来处理它。

+
第三个修改是现在成功时这个函数会返回一个Ok值。因为run函数签名中声明成功类型返回值是()，这意味着需要将 unit 类型值包装进Ok值中。Ok(())一开始看起来有点奇怪，不过这样使用()是表明我们调用run只是为了它的副作用的惯用方式；它并没有返回什么有意义的值。

 
上述代码能够编译，不过会有一个警告：

 
warning: unused result which must be used, #[warn(unused_must_use)] on by default
-  --> src\main.rs:39:5
+  --> src/main.rs:39:5
    |
 39 |     run(config);
    |     ^^^^^^^^^^^^
 

-
Rust 尝试告诉我们忽略Result，它有可能是一个错误值。让我们现在来处理它。我们将采用类似于列表 12-9 中处理Config::new错误的技巧，不过还有少许不同：

+
Rust 提示我们的代码忽略了Result值，它可能表明这里存在一个错误。虽然我们没有检查这里是否有一个错误，而编译器提醒我们这里应该有一些错误处理代码！现在就让我们修正他们。

+
处理main中run返回的错误

+
我们将检查错误并使用与列表 12-10 中处理错误类似的技术来优雅的处理他们，不过有一些细微的不同：

 
Filename: src/main.rs

 
fn main() {
     // ...snip...
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     if let Err(e) = run(config) {
@@ -6737,35 +6812,27 @@ fn run(config: Config) -> Result<(), Box<Error>> {
         process::exit(1);
     }
 }
-
-fn run(config: Config) -> Result<(), Box<Error>> {
-    let mut f = File::open(config.filename)?;
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)?;
-
-    println!("With text:\n{}", contents);
-
-    Ok(())
-}
 

 
-
不同于unwrap_or_else，我们使用if let来检查run是否返回Err，如果是则调用process::exit(1)。为什么呢？这个例子和Config::new的区别有些微妙。对于Config::new我们关心两件事：

-
    
-
  1. 检测出任何可能发生的错误
    2. 
-
  2. 如果没有出现错误创建一个Config
    3. 
-

-
而在这个情况下，因为run在成功的时候返回一个()，唯一需要担心的就是第一件事：检测错误。如果我们使用了unwrap_or_else，则会得到()的返回值。它并没有什么用处。

-
虽然两种情况下if let和unwrap_or_else的内容都是一样的：打印出错误并退出。

+
我们使用if let来检查run是否返回一个Err值，不同于unwrap_or_else，并在出错时调用process::exit(1)。run并不返回像Config::new返回的Config实例那样需要unwrap的值。因为run在成功时返回()，而我们只关心发现一个错误，所以并不需要unwrap_or_else来返回未封装的值，因为它只会是()。

+
不过两个例子中if let和unwrap_or_else的函数体都一样：打印出错误并退出。

 
将代码拆分到库 crate

-
现在项目看起来好多了！还有一件我们尚未开始的工作：拆分 src/main.rs 并将一些代码放入 src/lib.rs 中。让我们现在就开始吧：将 src/main.rs 中的run函数移动到新建的 src/lib.rs 中。还需要移动相关的use语句和Config的定义，以及其new方法。现在 src/lib.rs 应该如列表 12-12 所示：

+
现在项目看起来好多了！现在我们将要拆分 src/main.rs 并将一些代码放入 src/lib.rs，这样就能测试他们并拥有一个小的main函数。

+
让我们将如下代码片段从 src/main.rs 移动到新文件 src/lib.rs 中：

+
    
+
  • run函数定义
    • 
+
  • 相关的use语句
    • 
+
  • Config的定义
    • 
+
  • Config::new函数定义
    • 
+

+
现在 src/lib.rs 的内容应该看起来像列表 12-13：

 
Filename: src/lib.rs

 
use std::error::Error;
 use std::fs::File;
 use std::io::prelude::*;
 
 pub struct Config {
-    pub search: String,
+    pub query: String,
     pub filename: String,
 }
 
@@ -6775,11 +6842,11 @@ impl Config {
             return Err("not enough arguments");
         }
 
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Ok(Config {
-            search: search,
+            query: query,
             filename: filename,
         })
     }
@@ -6796,11 +6863,12 @@ pub fn run(config: Config) -> Result<(), Box<Error>>{
     Ok(())
 }
 

-
Listing 12-12: Moving Config and run into
+
Listing 12-13: Moving Config and run into
 src/lib.rs

 
-注意我们还需要使用公有的`pub`：在`Config`和其字段、它的`new`方法和`run`函数上。
-
现在在 src/main.rs 中，我们需要通过extern crate greprs来引入现在位于 src/lib.rs 的代码。接着需要增加一行use greprs::Config来引入Config到作用域，并对run函数加上 crate 名称前缀，如列表 12-13 所示：

+
这里使用了公有的pub：在Config、其字段和其new方法，以及run函数上。现在我们有了一个拥有可以测试的公有 API 的库 crate 了。

+
从二进制 crate 中调用库 crate

+
现在需要在 src/main.rs 中使用extern crate greprs将移动到 src/lib.rs 的代码引入二进制 crate 的作用域。接着我们将增加一个use greprs::Config行将Config类型引入作用域，并使用库 crate 的名称作为run函数的前缀，如列表 12-14 所示：

 
Filename: src/main.rs

 
extern crate greprs;
 
@@ -6817,7 +6885,7 @@ fn main() {
         process::exit(1);
     });
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     if let Err(e) = greprs::run(config) {
@@ -6827,12 +6895,17 @@ fn main() {
     }
 }
 

-
Listing 12-13: Bringing the greprs crate into the scope
+
Listing 12-14: Bringing the greprs crate into the scope
 of src/main.rs

 
-
-
通过这些重构，所有代码应该都能运行了。运行几次cargo run来确保你没有破坏什么内容。好的！确实有很多的内容，不过已经为将来的成功奠定了基础。我们采用了一种更加优秀的方式来处理错误，并使得代码更模块化了一些。从现在开始几乎所有的工作都将在 src/lib.rs 中进行。

-
让我们利用这新创建的模块的优势来进行一些在旧代码中难以开开展的工作，他们在新代码中却很简单：编写测试！

+
通过这些重构，所有功能应该抖联系在一起并可以运行了。运行cargo run来确保一切都正确的衔接在一起。

+
+
+
哇哦！这可有很多的工作，不过我们为将来成功打下了基础。现在处理错误将更容易，同时代码也更模块化。从现在开始几乎所有的工作都将在 src/lib.rs 中进行。

+
让我们利用这些新创建的模块的优势来进行一些在旧代码中难以展开的工作，他们在新代码中却很简单：编写测试！

 
测试库的功能

 

 
ch12-04-testing-the-librarys-functionality.md
@@ -9572,6 +9645,21 @@ impl AveragedCollection {
 }
 

 
Listing 17-2:在AveragedCollection结构体上实现了add、remove和average  public方法

+
public方法add、remove和average是修改AveragedCollection实例的唯一方式。当使用add方法把一个元素加入到list或者使用remove方法来删除它，这些方法的实现同时会调用私有的update_average方法来更新average成员变量。因为list和average是私有的，没有其他方式来使得外部的代码直接向list增加或者删除元素，直接操作list可能会引发average字段不同步。average方法返回average字段的值，这指的外部的代码只能读取average而不能修改它。

+
因为我们已经封装好了AveragedCollection的实现细节，所以我们也可以像使用list一样使用的一个不同的数据结构，比如用HashSet代替Vec。只要签名add、remove和average公有函数保持相同，使用AveragedCollection的代码无需改变。如果我们暴露List给外部代码时，未必都是这样，因为HashSet和Vec使用不同的函数增加元素，所以如果要想直接修改list的话，外部的代码可能还得修改。

+
如果封装是一个语言被认为是面向对象语言必要的方面的话，那么Rust满足要求。在代码中不同的部分使用或者不使用pub决定了实现细节的封装。

+
作为类型系统的继承和作为代码共享的继承

+
继承是一个很多编程语言都提供的机制，一个对象可以从另外一个对象的定义继承，这使得可以获得父对象的数据和行为，而不用重新定义。很多人定义面向对象语言时，认为继承是一个特色。

+
如果一个语言必须有继承才能被称为面向对象的语言，那么Rust就不是面向对象的。没有办法定义一个结构体继承自另外一个结构体，从而获得父结构体的成员和方法。然而，如果你过去常常在你的编程工具箱使用继承，依赖于你要使用继承的原因，在Rust中有其他的方式。

+
使用继承有两个主要的原因。第一个是为了重用代码：一旦一个特殊的行为从一个类型继承，继承可以在另外一个类型实现代码重用。Rust代码可以被共享通过使用默认的trait方法实现，可以在Listing 10-14看到，我们增加一个summary方法到Summarizabletrait。任何继承了Summarizabletrait的类型上会有summary方法，而无需任何的父代码。这类似于父类有一个继承的方法，一个从父类继承的子类也因为继承有了继承的方法。当实现Summarizabletrait时，我们也可以选择覆写默认的summary方法，这类似于子类覆写了从父类继承的实现方法。

+
第二个使用继承的原因是，使用类型系统：子类型可以在父类型被使用的地方使用。这也称为多态，意味着如果多种对象有一个相同的shape，它们可以被其他替代。

+

+
虽然很多人使用多态来描述继承，但是它实际上是一种特殊的多态，称为子类型多态。也有很多种其他形式，在Rust中带有通用的ttait绑定的一个参数
+也是多态——更特殊的类型多态。在多种类型的多态间的细节不是关键的，所以不要过于担心细节，只需要知道Rust有多种多态相关的特色就好，不像很多其他OOP语言。

+

+
为了支持这种样式，Rust有trait对象，这样我们可以指定给任何类型的值，只要值实现了一种特定的trait。

+
继承最近在很多编程语言的设计方案中失宠了。使用继承类实现代码重用需要共享比你需要共享的代码。子类不应该经常共享它们的父类的所有特色，但是继承意味着子类得到了它的父类的数据和行为。这使得一个程序的设计不灵活，创建了无意义的子类的方法被调用的可能性或者由于方法不适用于子类但是必须从父类继承，从而触发错误。另外，很多语言只允许从一个类继承，更加限制了程序设计的灵活性。

+
因为这些原因，Rust选择了一个另外的途径，使用trait替代继承。让我们看一下在Rust中trait对象是如何实现多态的。

 
                 
 
diff --git a/src/ch12-03-improving-error-handling-and-modularity.md b/src/ch12-03-improving-error-handling-and-modularity.md
index 3f1eebc..6e56835 100644
--- a/src/ch12-03-improving-error-handling-and-modularity.md
+++ b/src/ch12-03-improving-error-handling-and-modularity.md
@@ -1,4 +1,4 @@
-## 读取文件
+## 重构改进模块性和错误处理
 
 > [ch12-03-improving-error-handling-and-modularity.md](https://github.com/rust-lang/book/blob/master/second-edition/src/ch12-03-improving-error-handling-and-modularity.md)
 > 

@@ -18,24 +18,27 @@
 
 ### 二进制项目的关注分离
 
+`main`函数负责多个任务的组织问题在许多二进制项目中很常见。所以 Rust 社区开发出一个类在`main`函数开始变得庞大时进行二进制程序的关注分离的指导性过程。这些过程有如下步骤：
 
+1. 将程序拆分成 *main.rs* 和 *lib.rs* 并将程序的逻辑放入 *lib.rs* 中。
+2. 当命令行解析逻辑比较小时，可以保留在 *main.rs* 中。
+3. 当命令行解析开始变得复杂时，也同样将其从 *main.rs* 提取到 *lib.rs*中。
+4. 经过这些过程之后保留在`main`函数中的责任是：
+    * 使用参数值调用命令行解析逻辑
+    * 设置任何其他的配置
+    * 调用 *lib.rs* 中的`run`函数
+    * 如果`run`返回错误，则处理这个错误
 
+这个模式的一切就是为了关注分离：*main.rs* 处理程序运行，而 *lib.rs* 处理所有的真正的任务逻辑。因为不能直接测试`main`函数，这个结构通过将所有的程序逻辑移动到 *lib.rs* 的函数中使得我们可以测试他们。仅仅保留在 *main.rs* 中的代码将足够小以便阅读就可以验证其正确性。
 
 
+
+
 
+### 提取参数解析器
 
-这类项目组织上的问题在很多相似类型的项目中很常见，所以 Rust 社区开发出一种关注分离的组织模式。这种模式可以用来组织任何用 Rust 构建的二进制项目，所以可以证明应该更早的开始这项重构，以为我们的项目符合这个模式。这个模式看起来像这样：
-
-1. 将程序拆分成 *main.rs* 和 *lib.rs*。
-2. 将命令行参数解析逻辑放入 *main.rs*。
-3. 将程序逻辑放入 *lib.rs*。
-4. `main`函数的工作是：
-    * 解析参数
-    * 设置所有配置性变量
-    * 调用 *lib.rs* 中的`run`函数
-    * 如果`run`返回错误则处理这个错误
-
-好的！老实说这个模式好像还很复杂。这就是关注分离的所有内容：*main.rs* 负责实际的程序运行，而 *lib.rs* 处理所有真正的任务逻辑。让我们将程序重构成这种模式。首先，提取出一个目的只在于解析参数的函数。列表 12-4 中展示了一个新的开始，`main`函数调用了一个新函数`parse_config`，它仍然定义于 *src/main.rs* 中：
+首先，我们将提取解析参数的功能。列表 12-5 中展示了新`main`函数的开头，它调用了新函数`parse_config`。目前它仍将定义在 *src/main.rs* 中：
 
 Filename: src/main.rs
 
@@ -43,46 +46,63 @@
 fn main() {
     let args: Vec = env::args().collect();
 
-    let (search, filename) = parse_config(&args);
-
-    println!("Searching for {}", search);
-    println!("In file {}", filename);
+    let (query, filename) = parse_config(&args);
 
     // ...snip...
 }
 
 fn parse_config(args: &[String]) -> (&str, &str) {
-    let search = &args[1];
+    let query = &args[1];
     let filename = &args[2];
 
-    (search, filename)
+    (query, filename)
 }
 ```
 
-Listing 12-4: Extract a `parse_config` function from
+Listing 12-5: Extract a `parse_config` function from
 `main`
 
 
 
-这看起来好像有点复杂，不过我们将一点一点的开展重构。在做出这些改变之后，再次运行程序并验证参数解析是否仍然正常。经常验证你的进展是一个好习惯，这样在遇到问题时就能更好地理解什么修改造成了错误。
+我们仍然将命令行参数收集进一个 vector，不过不同于在`main`函数中将索引 1 的参数值赋值给变量`query`和将索引 2 的值赋值给变量`filename`，我们将整个 vector 传递给`parse_config`函数。接着`parse_config`函数将包含知道哪个参数该放入哪个变量的逻辑，并将这些值返回到`main`。仍然在`main`中创建变量`query`和`filename`，不过`main`不再负责处理命令行参数与变量如何对应。
+
+这对我们这小程序可能有点大材小用，不过我们将采用小的、增量的步骤进行重构。在做出这些改变之后，再次运行程序并验证参数解析是否仍然正常。经常验证你的进展是一个好习惯，这样在遇到问题时能帮助你定位问题的成因。
 
 ### 组合配置值
 
-现在我们有了一个函数了，让我们接着完善它。我们代码还能设计的更好一些：函数返回了一个元组，不过接着立刻就解构成了单独的部分。这些代码本身没有问题，不过有一个地方表明仍有改善的余地：我们调用了`parse_config`方法。函数名中的`config`部分也表明了返回的两个值应该是组合在一起的，因为他们都是某个配置值的一部分。
+我们可以采取另一个小的步骤来进一步改善这个函数。现在函数返回一个元组，不过立刻又就将元组拆成了独立的部分。这是一个我们可能没有进行正确抽象的信号。
+
+另一个表明还有改进空间的迹象是`parse_config`的`config`部分，它暗示了我们返回的两个值是相关的并都是一个配置值的一部分。目前除了将这两个值组合进元组之外并没有表达这个数据结构的意义：我们可以将这两个值放入一个结构体并给每个字段一个有意义的名字。这会让未来的维护者更容易理解不同的值如何相互关联以及他们的目的。
+
+
+
 
-> 注意：一些同学将当使用符合类型更为合适的时候使用基本类型当作一种称为**基本类型偏执**（*primitive obsession*）的反模式。
 
-让我们引入一个结构体来存放所有的配置。列表 12-5 中展示了新增的`Config`结构体定义、重构后的`parse_config`和`main`函数中的相关更新：
+> 注意：一些同学将这种当使用符合类型更为合适的时候使用基本类型的反模式称为**基本类型偏执**（*primitive obsession*）。
+
+
+
+
+列表 12-6 展示了新定义的结构体`Config`，它有字段`query`和`filename`。我们也改变了`parse_config`函数来返回一个`Config`结构体的实例，并更新`main`来使用结构体字段而不是单独的变量：
 
 Filename: src/main.rs
 
-```rust,ignore
+```rust,should_panic
+# use std::env;
+# use std::fs::File;
+#
 fn main() {
     let args: Vec = env::args().collect();
 
     let config = parse_config(&args);
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     let mut f = File::open(config.filename).expect("file not found");
@@ -91,83 +111,119 @@ fn main() {
 }
 
 struct Config {
-    search: String,
+    query: String,
     filename: String,
 }
 
 fn parse_config(args: &[String]) -> Config {
-    let search = args[1].clone();
+    let query = args[1].clone();
     let filename = args[2].clone();
 
     Config {
-        search: search,
+        query: query,
         filename: filename,
     }
 }
 ```
 
-Listing 12-5: Refactoring `parse_config` to return an
-instance of a `Config` struct
+Listing 12-6: Refactoring `parse_config` to return an instance of a `Config`
+struct
 
 
 
-`parse_config`的签名现在表明它返回一个`Config`值。在`parse_config`的函数体中，我们之前返回了`args`中`String`值引用的字符串 slice，不过`Config`定义为拥有两个有所有权的`String`值。因为`parse_config`的参数是一个`String`值的 slice，`Config`实例不能获取`String`值的所有权：这违反了 Rust 的借用规则，因为`main`函数中的`args`变量拥有这些`String`值并只允许`parse_config`函数借用他们。
+`parse_config`的签名现在表明它返回一个`Config`值。在`parse_config`的函数体中，之前返回了`args`中`String`值引用的字符串 slice，现在我们选择定义`Config`来使用拥有所有权的`String`值。`main`中的`args`变量是参数值的所有者并只允许`parse_config`函数借用他们，这意味着如果`Config`尝试获取`args`中值的所有权将违反 Rust 的借用规则。
 
-还有许多不同的方式可以处理`String`的数据；现在我们使用简单但低效率的方式，在字符串 slice 上调用`clone`方法。`clone`调用会生成一个字符串数据的完整拷贝，而且`Config`实例可以拥有它，不过这会消耗更多时间和内存来储存拷贝字符串数据的引用，不过拷贝数据让我们使我们的代码显得更加直白。
+还有许多不同的方式可以处理`String`的数据，而最简单但有些不太高效的方式是调用这些值的`clone`方法。这会生成`Config`实例可以拥有的数据的完整拷贝，不过会比储存字符串数据的引用消耗更多的时间和内存。不过拷贝数据使得代码显得更加直白因为无需管理引用的生命周期，所以在这种情况下牺牲一小部分性能来换取简洁性的取舍是值得的。
 
 
 
 > #### 使用`clone`权衡取舍
 >
-> 由于其运行时消耗，许多 Rustacean 之间有一个趋势是倾向于不使用`clone`来解决所有权问题。在关于迭代器的第十三章中，我们将会学习如何更有效率的处理这种情况。现在，为了编写我们的程序拷贝一些字符串是没有问题。我们只进行了一次拷贝，而且文件名和要搜索的字符串都比较短。随着你对 Rust 更加熟练，将更轻松的省略这个权衡的步骤，不过现在调用`clone`是完全可以接受的。
+> 由于其运行时消耗，许多 Rustacean 之间有一个趋势是倾向于避免使用`clone`来解决所有权问题。在关于迭代器的第十三章中，我们将会学习如何更有效率的处理这种情况，不过现在，复制一些字符串来取得进展是没有问题的，因为只会进行一次这样的拷贝，而且文件名和要搜索的字符串都比较短。在第一轮编写时拥有一个可以工作但有点低效的程序要比尝试过度优化代码更好一些。随着你对 Rust 更加熟练，将能更轻松的直奔合适的方法，不过现在调用`clone`是完全可以接受的。
 
 
 
-`main`函数更新为将`parse_config`返回的`Config`实例放入变量`config`中，并将分别使用`search`和`filename`变量的代码更新为使用`Config`结构体的字段。
+我们更新`main`将`parse_config`返回的`Config`实例放入变量`config`中，并更新之前分别使用`search`和`filename`变量的代码为现在的使用`Config`结构体的字段。
+
+现在代码更明确的表现了我们的意图，`query`和`filename`是相关联的并且他们的目的是配置程序如何工作的。任何使用这些值的代码就知道在`config`实例中对应目的的字段名中寻找他们。
 
 ### 创建一个`Config`构造函数
 
-现在让我们考虑一下`parse_config`的目的：这是一个创建`Config`示例的函数。我们已经见过了一个创建实例函数的规范：像`String::new`这样的`new`函数。列表 12-6 中展示了将`parse_config`转换为一个`Config`结构体关联函数`new`的代码：
+
+
+
+目前为止，我们将负责解析命令行参数的逻辑从`main`提取到了`parse_config`函数中，这帮助我们看清值`query`和`filename`是相互关联的并应该在代码中表现这种关系。接着我们增加了`Config`结构体来命名`query`和`filename`的相关目的，并能够从`parse_config`函数中将这些值的名称作为结构体字段名称返回。
+
+所以现在`parse_config`函数的目的是创建一个`Config`实例，我们可以将`parse_config`从一个普通函数变为一个叫做`new`的与结构体关联的函数。做出这个改变使得代码更符合习惯：可以像标准库中的`String`调用`String::new`来创建一个该类型的实例那样，将`parse_config`变为一个与`Config`关联的`new`函数。列表 12-7 展示了需要做出的修改：
 
 Filename: src/main.rs
 
-```rust,ignore
+```rust,should_panic
+# use std::env;
+#
 fn main() {
     let args: Vec = env::args().collect();
 
     let config = Config::new(&args);
 
-    println!("Searching for {}", config.search);
-    println!("In file {}", config.filename);
-
     // ...snip...
 }
 
+# struct Config {
+#     query: String,
+#     filename: String,
+# }
+#
 // ...snip...
 
 impl Config {
     fn new(args: &[String]) -> Config {
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Config {
-            search: search,
+            query: query,
             filename: filename,
         }
     }
 }
 ```
 
-Listing 12-6: Changing `parse_config` into
+Listing 12-7: Changing `parse_config` into
 `Config::new`
 
 
 
-我们将`parse_config`的名字改为`new`并将其移动到`impl`块中。我们也更新了`main`中的调用代码。再次尝试编译并确保程序可以运行。
+这里将`main`中调用`parse_config`的地方更新为调用`Config::new`。我们将`parse_config`的名字改为`new`并将其移动到`impl`块中，这使得`new`函数与`Config`相关联。再次尝试编译并确保它可以工作。
+
+### 修复错误处理
+
+现在我们开始修复错误处理。回忆一下之前提到过如果`args` vector 包含少于 3 个项并尝试访问 vector 中索引 1 或 索引 2 的值会造成程序 panic。尝试不带任何参数运行程序；这将看起来像这样：
+
+```
+$ cargo run
+    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
+     Running `target/debug/greprs`
+thread 'main' panicked at 'index out of bounds: the len is 1
+but the index is 1',  /stable-dist-rustc/build/src/libcollections/vec.rs:1307
+note: Run with `RUST_BACKTRACE=1` for a backtrace.
+```
 
-### 从构造函数返回`Result`
+`index out of bounds: the len is 1 but the index is 1`是一个针对程序员的错误信息，这并不能真正帮助终端用户理解发生了什么和相反他们应该做什么。现在就让我们修复它吧。
 
-这是我们对这个方法最后的重构：还记得当 vector 含有少于三个项时访问索引 1 和 2 会 panic 并给出一个糟糕的错误信息的代码吗？让我们来修改它！列表 12-7 展示了如何在访问这些位置之前检查 slice 是否足够长，并使用一个更好的 panic 信息：
+### 改善错误信息
+
+在列表 12-8 中，在`new`函数中增加了一个检查在访问索引 1 和 2 之前检查 slice 是否足够长。如果 slice 不够长，我们使用一个更好的错误信息 panic 而不是`index out of bounds`信息：
 
 Filename: src/main.rs
 
@@ -177,28 +233,38 @@ fn new(args: &[String]) -> Config {
     if args.len() < 3 {
         panic!("not enough arguments");
     }
-
-    let search = args[1].clone();
     // ...snip...
-}
 ```
 
-Listing 12-7: Adding a check for the number of
+Listing 12-8: Adding a check for the number of
 arguments
 
 
 
-通过在`new`中添加这额外的几行代码，再次尝试不带参数运行程序：
+这类似于列表 9-8 中的`Guess::new`函数，那里如果`value`参数超出了有效值的范围就调用`panic!`。不同于检查值的范围，这里检查`args`的长度至少是 3，而函数的剩余部分则可以假设这个条件成立的基础上运行。如果
+`args`少于 3 个项，这个条件将为真，并调用`panic!`立即终止程序。
+
+有了`new`中这几行额外的代码，再次不带任何参数运行程序并看看现在错误看起来像什么：
 
 ```
 $ cargo run
     Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target\debug\greprs.exe`
-thread 'main' panicked at 'not enough arguments', src\main.rs:29
+     Running `target/debug/greprs`
+thread 'main' panicked at 'not enough arguments', src/main.rs:29
 note: Run with `RUST_BACKTRACE=1` for a backtrace.
 ```
 
-这样就好多了！至少有个一个符合常理的错误信息。然而，还有一堆额外的信息我们并不希望提供给用户。可以通过改变`new`的签名来完善它。现在它只返回了一个`Config`，所有没有办法表示创建`Config`失败的情况。相反，可以如列表 12-8 所示返回一个`Result`：
+这个输出就好多了，现在有了一个合理的错误信息。然而，我们还有一堆额外的信息不希望提供给用户。所以在这里使用列表 9-8 中的技术可能不是最好的；无论如何`panic!`调用更适合程序问题而不是使用问题，正如第九章所讲到的。相反我们可以使用那一章学习的另一个技术：返回一个可以表明成功或错误的`Result`。
+
+
+
+
+#### 从`new`中返回`Result`而不是调用`panic!`
+
+我们可以选择返回一个`Result`值，它在成功时会包含一个`Config`的实例，而在错误时会描述问题。当`Config::new`与`main`交流时，在使用`Result`类型存在问题时可以使用 Rust 的信号方式。接着修改`main`将`Err`成员转换为对用户更友好的错误，而不是`panic!`调用产生的关于`thread 'main'`和`RUST_BACKTRACE`的文本。
+
+列表 12-9 展示了`Config::new`返回值和函数体中返回`Result`所需的改变：
 
 Filename: src/main.rs
 
@@ -209,33 +275,38 @@ impl Config {
             return Err("not enough arguments");
         }
 
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Ok(Config {
-            search: search,
+            query: query,
             filename: filename,
         })
     }
 }
 ```
 
-Listing 12-8: Return a `Result` from `Config::new`
+Listing 12-9: Return a `Result` from `Config::new`
 
 
 
-现在`new`函数返回一个`Result`，在成功时带有一个`Config`实例而在出现错误时带有一个`&'static str`。回忆一下第十章“静态声明周期”中讲到`&'static str`是一个字符串字面值，他也是现在我们的错误信息。
+
+
+
+现在`new`函数返回一个`Result`，在成功时带有一个`Config`实例而在出现错误时带有一个`&'static str`。回忆一下第十章“静态声明周期”中讲到`&'static str`是一个字符串字面值，也是目前的错误信息。
 
 `new`函数体中有两处修改：当没有足够参数时不再调用`panic!`，而是返回`Err`值。同时我们将`Config`返回值包装进`Ok`成员中。这些修改使得函数符合其新的类型签名。
 
-### `Config::new`调用和错误处理
+通过让`Config::new`返回一个`Err`值，这就允许`main`函数处理`new`函数返回的`Result`值并在出现错误的情况更明确的结束进程。
+
+### `Config::new`调用并处理错误
 
-现在我们需要对`main`做一些修改，如列表 12-9 所示：
+为了处理错误情况并打印一个对用户友好的信息，我们需要像列表 12-10 那样更新`main`函数来处理现在`Config::new`返回的`Result`。另外还需要实现一些`panic!`替我们处理的问题：使用错误码 1 退出命令行工具。非零的退出状态是一个告诉调用程序的进程我们的程序以错误状态退出的惯例信号。
 
 Filename: src/main.rs
 
 ```rust,ignore
-// ...snip...
 use std::process;
 
 fn main() {
@@ -246,36 +317,54 @@ fn main() {
         process::exit(1);
     });
 
-    println!("Searching for {}", config.search);
-    println!("In file {}", config.filename);
-
     // ...snip...
 ```
 
-Listing 12-9: Exiting with an error code if creating a
+Listing 12-10: Exiting with an error code if creating a
 new `Config` fails
 
 
 
-新增了一个`use`行来从标准库中导入`process`。在`main`函数中我们将处理`new`函数返回的`Result`值，并在其返回`Config::new`时以一种更加清楚的方式结束进程。
+
+
+
 
-这里使用了一个之前没有讲到的标准库中定义的`Result`的方法：`unwrap_or_else`。当`Result`是`Ok`时其行为类似于`unwrap`：它返回`Ok`内部封装的值。与`unwrap`不同的是，当`Result`是`Err`时，它调用一个**闭包**（*closure*），也就是一个我们定义的作为参数传递给`unwrap_or_else`的匿名函数。第十三章会更详细的介绍闭包；这里需要理解的重要部分是`unwrap_or_else`会将`Err`的内部值传递给闭包中位于两道竖线间的参数`err`。使用`unwrap_or_else`允许我们进行一些自定义的非`panic!`的错误处理。
+在上面的列表中，使用了一个之前没有涉及到的方法：`unwrap_or_else`，它定义于标准库的`Result`上。使用`unwrap_or_else`可以进行一些自定义的非`panic!`的错误处理。当`Result`是`Ok`时，这个方法的行为类似于`unwrap`：它返回`Ok`内部封装的值。然而，当`Result`是`Err`时，它调用一个**闭包**（*closure*），也就是一个我们定义的作为参数传递给`unwrap_or_else`的匿名函数。第十三章会更详细的介绍闭包。现在你需要理解的是`unwrap_or_else`会将`Err`的内部值，也就是列表 12-9 中增加的`not enough arguments`静态字符串的情况，传递给闭包中位于两道竖线间的参数`err`。闭包中的代码在其运行时可以使用这个`err`值。
 
-上述的错误处理其实只有两行：我们打印出了错误，接着调用了`std::process::exit`。这个函数立刻停止程序的执行并将传递给它的数组作为返回码。依照惯例，零代表成功而任何其他数字表示失败。就结果来说这依然类似于列表 12-7 中的基于`panic!`的错误处理，但是不再会有额外的输出了，让我们试一试：
+
+
+
+我们新增了一个`use`行来从标准库中导入`process`。在错误的情况闭包中将被运行的代码只有两行：我们打印出了`err`值，接着调用了`std::process::exit`（在开头增加了新的`use`行从标准库中导入了`process`）。`process::exit`会立即停止程序并将传递给它的数字作为返回状态码。这类似于列表 12-8 中使用的基于`panic!`的错误处理，除了不会在得到所有的额外输出了。让我们试试：
 
 ```
 $ cargo run
    Compiling greprs v0.1.0 (file:///projects/greprs)
     Finished debug [unoptimized + debuginfo] target(s) in 0.48 secs
-     Running `target\debug\greprs.exe`
+     Running `target/debug/greprs`
 Problem parsing arguments: not enough arguments
 ```
 
-非常好！现在输出就友好多了。
+非常好！现在输出对于用户来说就友好多了。
+
+### 提取`run`函数
 
-### `run`函数中的错误处理
+现在我们完成了配置解析的重构：让我们转向程序的逻辑。正如“二进制项目的关注分离”部分的讨论所留下的过程，我们将提取一个叫做`run`的函数来存放目前`main`函数中不属于设置配置或处理错误的所有逻辑。一旦完成这些，`main`函数将简明的足以通过观察来验证，而我们将能够为所有其他逻辑编写测试。
 
-现在重构完了参数解析部分，让我们再改进一下程序的逻辑。列表 12-10 中展示了在`main`函数中调用提取出函数`run`之后的代码。`run`函数包含之前位于`main`中的部分代码：
+
+
+
+列表 12-11 展示了提取出来的`run`函数。目前我们只进行小的增量式的提取函数的改进并仍将在 *src/main.rs* 中定义这个函数：
 
 Filename: src/main.rs
 
@@ -283,7 +372,7 @@ Problem parsing arguments: not enough arguments
 fn main() {
     // ...snip...
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     run(config);
@@ -301,12 +390,16 @@ fn run(config: Config) {
 // ...snip...
 ```
 
-Listing 12-10: Extracting a `run` functionality for the
+Listing 12-11: Extracting a `run` function containing the
 rest of the program logic
 
 
 
-`run`函数的内容是之前位于`main`中的几行，而且`run`函数获取一个`Config`作为参数。现在有了一个单独的函数了，我们就可以像列表 12-8 中的`Config::new`那样进行类似的改进了。列表 12-11 展示了另一个`use`语句将`std::error::Error`结构引入了作用域，还有使`run`函数返回`Result`的修改：
+现在`run`函数包含了`main`中从读取文件开始的剩余的所有逻辑。`run`函数获取一个`Config`实例作为参数。
+
+#### 从`run`函数中返回错误
+
+通过将剩余的逻辑分离进`run`函数而不是留在`main`中，就可以像列表 12-9 中的`Config::new`那样改进错误处理。不再通过通过`expect`允许程序 panic，`run`函数将会在出错时返回一个`Result`。这让我们进一步以一种对用户友好的方式统一`main`中的错误处理。列表 12-12 展示了`run`签名和函数体中的变化：
 
 Filename: src/main.rs
 
@@ -327,28 +420,38 @@ fn run(config: Config) -> Result<(), Box> {
 }
 ```
 
-Listing 12-11: Changing the `run` function to return
+Listing 12-12: Changing the `run` function to return
 `Result`
 
 
 
-这里有三个大的修改。第一个是现在`run`函数的返回值是`Result<(), Box>`类型的。之前，函数返回 unit 类型`()`，现在它仍然是`Ok`时的返回值。对于错误类型，我们将使用`Box`。这是一个**trait 对象**（*trait object*），第XX章会讲到。现在可以这样理解它：`Box`意味着函数返回了某个实现了`Error` trait 的类型，不过并没有指定具体的返回值类型。这样就比较灵活，因为在不同的错误场景可能有不同类型的错误返回值。`Box`是一个堆数据的智能指针，第十五章将会详细介绍`Box`。
+这里做出了三个大的改变。第一，改变了`run`函数的返回值为`Result<(), Box>`。之前这个函数返回 unit 类型`()`，现在它仍然保持作为`Ok`时的返回值。
+
+
+
 
-第二个改变是我们去掉了`expect`调用并替换为第9章讲到的`?`。不同于遇到错误就`panic!`，这会从函数中返回错误值并让调用者来处理它。
+对于错误类型，使用了**trait 对象**`Box`（在开头使用了`use`语句将`std::error::Error`引入作用域）。第十七章会涉及 trait 对象。目前只需知道`Box`意味着函数会返回实现了`Error` trait 的类型，不过无需指定具体将会返回的值的类型。这提供了在不同的错误场景可能有不同类型的错误返回值的灵活性。
 
-第三个修改是现在成功时这个函数会返回一个`Ok`值。因为`run`函数签名中声明成功类型返回值是`()`，所以需要将 unit 类型值包装进`Ok`值中。`Ok(())`一开始看起来有点奇怪，不过这样使用`()`是表明我们调用`run`只是为了它的副作用的惯用方式；它并没有返回什么有意义的值。
+第二个改变是去掉了`expect`调用并替换为第九章讲到的`?`。不同于遇到错误就`panic!`，这会从函数中返回错误值并让调用者来处理它。
+
+第三个修改是现在成功时这个函数会返回一个`Ok`值。因为`run`函数签名中声明成功类型返回值是`()`，这意味着需要将 unit 类型值包装进`Ok`值中。`Ok(())`一开始看起来有点奇怪，不过这样使用`()`是表明我们调用`run`只是为了它的副作用的惯用方式；它并没有返回什么有意义的值。
 
 上述代码能够编译，不过会有一个警告：
 
 ```
 warning: unused result which must be used, #[warn(unused_must_use)] on by default
-  --> src\main.rs:39:5
+  --> src/main.rs:39:5
    |
 39 |     run(config);
    |     ^^^^^^^^^^^^
 ```
 
-Rust 尝试告诉我们忽略`Result`，它有可能是一个错误值。让我们现在来处理它。我们将采用类似于列表 12-9 中处理`Config::new`错误的技巧，不过还有少许不同：
+Rust 提示我们的代码忽略了`Result`值，它可能表明这里存在一个错误。虽然我们没有检查这里是否有一个错误，而编译器提醒我们这里应该有一些错误处理代码！现在就让我们修正他们。
+
+#### 处理`main`中`run`返回的错误
+
+我们将检查错误并使用与列表 12-10 中处理错误类似的技术来优雅的处理他们，不过有一些细微的不同：
 
 Filename: src/main.rs
 
@@ -356,7 +459,7 @@ Rust 尝试告诉我们忽略`Result`，它有可能是一个错误值。让我
 fn main() {
     // ...snip...
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     if let Err(e) = run(config) {
@@ -365,33 +468,26 @@ fn main() {
         process::exit(1);
     }
 }
-
-fn run(config: Config) -> Result<(), Box> {
-    let mut f = File::open(config.filename)?;
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)?;
-
-    println!("With text:\n{}", contents);
-
-    Ok(())
-}
 ```
 
 
 
-不同于`unwrap_or_else`，我们使用`if let`来检查`run`是否返回`Err`，如果是则调用`process::exit(1)`。为什么呢？这个例子和`Config::new`的区别有些微妙。对于`Config::new`我们关心两件事：
+我们使用`if let`来检查`run`是否返回一个`Err`值，不同于`unwrap_or_else`，并在出错时调用`process::exit(1)`。`run`并不返回像`Config::new`返回的`Config`实例那样需要`unwrap`的值。因为`run`在成功时返回`()`，而我们只关心发现一个错误，所以并不需要`unwrap_or_else`来返回未封装的值，因为它只会是`()`。
 
-1. 检测出任何可能发生的错误
-2. 如果没有出现错误创建一个`Config`
+不过两个例子中`if let`和`unwrap_or_else`的函数体都一样：打印出错误并退出。
 
-而在这个情况下，因为`run`在成功的时候返回一个`()`，唯一需要担心的就是第一件事：检测错误。如果我们使用了`unwrap_or_else`，则会得到`()`的返回值。它并没有什么用处。
+### 将代码拆分到库 crate
 
-虽然两种情况下`if let`和`unwrap_or_else`的内容都是一样的：打印出错误并退出。
+现在项目看起来好多了！现在我们将要拆分 *src/main.rs* 并将一些代码放入 *src/lib.rs*，这样就能测试他们并拥有一个小的`main`函数。
 
-### 将代码拆分到库 crate
+让我们将如下代码片段从 *src/main.rs* 移动到新文件 *src/lib.rs* 中：
+
+- `run`函数定义
+- 相关的`use`语句
+- `Config`的定义
+- `Config::new`函数定义
 
-现在项目看起来好多了！还有一件我们尚未开始的工作：拆分 *src/main.rs* 并将一些代码放入 *src/lib.rs* 中。让我们现在就开始吧：将 *src/main.rs* 中的`run`函数移动到新建的 *src/lib.rs* 中。还需要移动相关的`use`语句和`Config`的定义，以及其`new`方法。现在 *src/lib.rs* 应该如列表 12-12 所示：
+现在 *src/lib.rs* 的内容应该看起来像列表 12-13：
 
 Filename: src/lib.rs
 
@@ -401,7 +497,7 @@ use std::fs::File;
 use std::io::prelude::*;
 
 pub struct Config {
-    pub search: String,
+    pub query: String,
     pub filename: String,
 }
 
@@ -411,11 +507,11 @@ impl Config {
             return Err("not enough arguments");
         }
 
-        let search = args[1].clone();
+        let query = args[1].clone();
         let filename = args[2].clone();
 
         Ok(Config {
-            search: search,
+            query: query,
             filename: filename,
         })
     }
@@ -433,13 +529,16 @@ pub fn run(config: Config) -> Result<(), Box>{
 }
 ```
 
-Listing 12-12: Moving `Config` and `run` into
+Listing 12-13: Moving `Config` and `run` into
 *src/lib.rs*
 
 
-注意我们还需要使用公有的`pub`：在`Config`和其字段、它的`new`方法和`run`函数上。
 
-现在在 *src/main.rs* 中，我们需要通过`extern crate greprs`来引入现在位于 *src/lib.rs* 的代码。接着需要增加一行`use greprs::Config`来引入`Config`到作用域，并对`run`函数加上 crate 名称前缀，如列表 12-13 所示：
+这里使用了公有的`pub`：在`Config`、其字段和其`new`方法，以及`run`函数上。现在我们有了一个拥有可以测试的公有 API 的库 crate 了。
+
+#### 从二进制 crate 中调用库 crate
+
+现在需要在 *src/main.rs* 中使用`extern crate greprs`将移动到 *src/lib.rs* 的代码引入二进制 crate 的作用域。接着我们将增加一个`use greprs::Config`行将`Config`类型引入作用域，并使用库 crate 的名称作为`run`函数的前缀，如列表 12-14 所示：
 
 Filename: src/main.rs
 
@@ -459,7 +558,7 @@ fn main() {
         process::exit(1);
     });
 
-    println!("Searching for {}", config.search);
+    println!("Searching for {}", config.query);
     println!("In file {}", config.filename);
 
     if let Err(e) = greprs::run(config) {
@@ -470,13 +569,21 @@ fn main() {
 }
 ```
 
-Listing 12-13: Bringing the `greprs` crate into the scope
+Listing 12-14: Bringing the `greprs` crate into the scope
 of *src/main.rs*
 
 
 
-
 
-通过这些重构，所有代码应该都能运行了。运行几次`cargo run`来确保你没有破坏什么内容。好的！确实有很多的内容，不过已经为将来的成功奠定了基础。我们采用了一种更加优秀的方式来处理错误，并使得代码更模块化了一些。从现在开始几乎所有的工作都将在 *src/lib.rs* 中进行。
 
-让我们利用这新创建的模块的优势来进行一些在旧代码中难以开开展的工作，他们在新代码中却很简单：编写测试！
\ No newline at end of file
+通过这些重构，所有功能应该抖联系在一起并可以运行了。运行`cargo run`来确保一切都正确的衔接在一起。
+
+
+
+
+哇哦！这可有很多的工作，不过我们为将来成功打下了基础。现在处理错误将更容易，同时代码也更模块化。从现在开始几乎所有的工作都将在 *src/lib.rs* 中进行。
+
+让我们利用这些新创建的模块的优势来进行一些在旧代码中难以展开的工作，他们在新代码中却很简单：编写测试！
\ No newline at end of file