重构以改进模块化和错误处理

我们仍在将命令行参数收集到一个向量中，但我们没有将索引 1 处的参数值分配给变量 query，并将索引 2 处的参数值分配给 main 函数中的变量 file_path，而是将整个向量传递给 parse_config 函数。然后，parse_config 函数保存确定哪个参数进入哪个变量的逻辑，并将值传递回 main。我们仍在 main 中创建 query 和 file_path 变量，但 main 不再负责确定命令行参数和变量如何对应。

对于我们的小程序来说，这种重构似乎有些大材小用，但我们正在以小的、增量的步骤进行重构。进行此更改后，再次运行程序以验证参数解析是否仍然有效。经常检查进度是一个好习惯，有助于在出现问题时识别原因。

对配置值进行分组

我们可以采取另一个小步骤来进一步改进 parse_config 函数。目前，我们正在返回一个元组，但随后我们立即将该元组再次分解为各个部分。这表明我们可能还没有找到正确的抽象。

另一个表明还有改进空间的指标是 parse_config 中的 config 部分，这意味着我们返回的两个值是相关的，并且都是一个配置值的一部分。除了将两个值分组到一个元组中之外，我们目前没有在数据结构中传达这种含义；我们将把这两个值放入一个结构体中，并为每个结构体字段指定一个有意义的名称。这样做将使该代码的未来维护者更容易理解不同的值如何相互关联以及它们的用途。

清单 12-6 显示了对 parse_config 函数的改进。

文件名：src/main.rs

use std::env;
use std::fs;

fn main() {
    let args: Vec<String> = env::args().collect();

    let config = parse_config(&args);

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    let contents = fs::read_to_string(config.file_path)
        .expect("Should have been able to read the file");

    // --snip--

    println!("With text:\n{contents}");
}

struct Config {
    query: String,
    file_path: String,
}

fn parse_config(args: &[String]) -> Config {
    let query = args[1].clone();
    let file_path = args[2].clone();

    Config { query, file_path }
}

清单 12-6：重构 parse_config 以返回 Config 结构体的实例

我们添加了一个名为 Config 的结构体，该结构体定义为具有名为 query 和 file_path 的字段。parse_config 的签名现在指示它返回一个 Config 值。在 parse_config 的主体中，我们过去常常返回引用 args 中的 String 值的字符串切片，现在我们定义 Config 以包含拥有的 String 值。main 中的 args 变量是参数值的所有者，并且只允许 parse_config 函数借用它们，这意味着如果 Config 试图获取 args 中的值的所有权，我们将违反 Rust 的借用规则。

我们可以通过多种方式管理 String 数据；最简单但效率 somewhat 低下的方法是在值上调用 clone 方法。这将为 Config 实例创建一个完整的数据副本以供其拥有，这比存储对字符串数据的引用需要更多的时间和内存。但是，克隆数据也使我们的代码非常简单，因为我们不必管理引用的生命周期；在这种情况下，为了获得简单性而牺牲一点性能是值得的。

使用 clone 的权衡

许多 Rustacean 倾向于避免使用 clone 来解决所有权问题，因为它会增加运行时成本。在第 13 章中，你将学习如何在这种情况下使用更有效的方法。但就目前而言，复制一些字符串以继续取得进展是可以的，因为你只会进行一次复制，而且你的文件路径和查询字符串非常小。最好是拥有一个效率稍低的有效程序，而不是在第一次尝试时就试图对代码进行过度优化。随着你对 Rust 越来越有经验，从最有效的解决方案开始会更容易，但就目前而言，调用 clone 是完全可以接受的。

我们更新了 main，以便将 parse_config 返回的 Config 实例放入名为 config 的变量中，并且我们更新了以前使用单独的 query 和 file_path 变量的代码，以便现在使用 Config 结构体上的字段。

现在，我们的代码更清楚地表明 query 和 file_path 是相关的，并且它们的目的是配置程序的工作方式。任何使用这些值的代码都知道在名为 config 的实例中找到它们，这些字段以其用途命名。

为 `Config` 创建构造函数

到目前为止，我们已经从 main 中提取了负责解析命令行参数的逻辑，并将其放置在 parse_config 函数中。这样做有助于我们了解到 query 和 file_path 值是相关的，并且这种关系应该在我们的代码中体现出来。然后，我们添加了一个 Config 结构体来命名 query 和 file_path 的相关用途，并能够从 parse_config 函数中返回这些值的名称作为结构体字段名称。

因此，既然 parse_config 函数的目的是创建一个 Config 实例，我们可以将 parse_config 从一个普通函数更改为一个名为 new 的函数，该函数与 Config 结构体相关联。进行此更改将使代码更符合习惯用法。我们可以通过调用 String::new 来创建标准库中类型的实例，例如 String。类似地，通过将 parse_config 更改为与 Config 关联的 new 函数，我们将能够通过调用 Config::new 来创建 Config 的实例。清单 12-7 显示了我们需要进行的更改。

文件名：src/main.rs

use std::env;
use std::fs;

fn main() {
    let args: Vec<String> = env::args().collect();

    let config = Config::new(&args);

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    let contents = fs::read_to_string(config.file_path)
        .expect("Should have been able to read the file");

    println!("With text:\n{contents}");

    // --snip--
}

// --snip--

struct Config {
    query: String,
    file_path: String,
}

impl Config {
    fn new(args: &[String]) -> Config {
        let query = args[1].clone();
        let file_path = args[2].clone();

        Config { query, file_path }
    }
}

清单 12-7：将 parse_config 更改为 Config::new

我们更新了 main，将调用 parse_config 的地方改为调用 Config::new。我们将 parse_config 的名称更改为 new，并将其移至 impl 块中，该块将 new 函数与 Config 关联起来。再次尝试编译此代码以确保其正常工作。

修复错误处理

现在我们将着手修复错误处理。回想一下，如果向量包含少于三个项目，则尝试访问索引 1 或索引 2 处的 args 向量中的值将导致程序崩溃。尝试在没有任何参数的情况下运行程序；它看起来像这样

$ cargo run
   Compiling minigrep v0.1.0 (file:///projects/minigrep)
    Finished dev [unoptimized + debuginfo] target(s) in 0.0s
     Running `target/debug/minigrep`
thread 'main' panicked at src/main.rs:27:21:
index out of bounds: the len is 1 but the index is 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

“index out of bounds: the len is 1 but the index is 1”这一行是面向程序员的错误消息。它不会帮助我们的最终用户理解他们应该做什么。让我们现在就解决这个问题。

改进错误消息

在清单 12-8 中，我们在 new 函数中添加了一个检查，该检查将在访问索引 1 和 2 之前验证切片是否足够长。如果切片不够长，程序将崩溃并显示一条更好的错误消息。

文件名：src/main.rs

use std::env;
use std::fs;

fn main() {
    let args: Vec<String> = env::args().collect();

    let config = Config::new(&args);

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    let contents = fs::read_to_string(config.file_path)
        .expect("Should have been able to read the file");

    println!("With text:\n{contents}");
}

struct Config {
    query: String,
    file_path: String,
}

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

        let query = args[1].clone();
        let file_path = args[2].clone();

        Config { query, file_path }
    }
}

清单 12-8：添加对参数数量的检查

这段代码类似于我们在清单 9-13 中编写的 Guess::new 函数，当 value 参数超出有效值范围时，我们调用了 panic!。这里我们没有检查值的范围，而是检查 args 的长度是否至少为 3，并且函数的其余部分可以在满足此条件的假设下运行。如果 args 的项目少于三个，则此条件为真，并且我们调用 panic! 宏立即结束程序。

在 new 中添加了这几行代码后，让我们再次在没有任何参数的情况下运行程序，看看现在的错误是什么样子

$ cargo run
   Compiling minigrep v0.1.0 (file:///projects/minigrep)
    Finished dev [unoptimized + debuginfo] target(s) in 0.0s
     Running `target/debug/minigrep`
thread 'main' panicked at src/main.rs:26:13:
not enough arguments
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

此输出更好：我们现在有了一个合理的错误消息。但是，我们也有不想提供给用户的无关信息。也许我们在这里使用清单 9-13 中使用的技术并不是最好的：正如第 9 章中所讨论的，调用 panic! 更适合于编程问题，而不是使用问题。相反，我们将使用你在第 9 章中学到的另一种技术，即返回一个 Result来指示成功或错误。

返回 `Result` 而不是调用 `panic!`

我们可以改为返回一个 Result 值，该值在成功的情况下将包含一个 Config 实例，并在错误的情况下描述问题。我们还将把函数名从 new 更改为 build，因为许多程序员希望 new 函数永远不会失败。当 Config::build 与 main 通信时，我们可以使用 Result 类型来表示出现了问题。然后，我们可以更改 main，将 Err 变体转换为对用户更实际的错误，而不会出现调用 panic! 导致的有关 thread 'main' 和 RUST_BACKTRACE 的周围文本。

清单 12-9 显示了我们需要对现在称为 Config::build 的函数的返回值以及返回 Result 所需的函数体进行的更改。请注意，在我们更新 main 之前，这不会编译，我们将在下一个清单中进行更新。

文件名：src/main.rs

use std::env;
use std::fs;

fn main() {
    let args: Vec<String> = env::args().collect();

    let config = Config::new(&args);

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    let contents = fs::read_to_string(config.file_path)
        .expect("Should have been able to read the file");

    println!("With text:\n{contents}");
}

struct Config {
    query: String,
    file_path: String,
}

impl Config {
    fn build(args: &[String]) -> Result<Config, &'static str> {
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let file_path = args[2].clone();

        Ok(Config { query, file_path })
    }
}

清单 12-9：从 Config::build 返回 Result

我们的 build 函数返回一个 Result，在成功的情况下包含一个 Config 实例，在错误的情况下包含一个 &'static str。我们的错误值将始终是具有 'static 生命周期字符串字面量。

我们在函数体中做了两处更改：当用户没有传递足够的参数时，我们不再调用 panic!，而是返回一个 Err 值，并且我们将 Config 返回值包装在一个 Ok 中。这些更改使函数符合其新的类型签名。

从 Config::build 返回 Err 值允许 main 函数处理从 build 函数返回的 Result 值，并在错误情况下更干净地退出进程。

调用 `Config::build` 并处理错误

为了处理错误情况并打印用户友好的消息，我们需要更新 main 以处理 Config::build 返回的 Result，如清单 12-10 所示。我们还将把使用非零错误代码退出命令行工具的责任从 panic! 中移除，而是手动实现它。非零退出状态是一种约定，用于向调用我们程序的进程发出信号，表明程序以错误状态退出。

文件名：src/main.rs

use std::env;
use std::fs;
use std::process;

fn main() {
    let args: Vec<String> = env::args().collect();

    let config = Config::build(&args).unwrap_or_else(|err| {
        println!("Problem parsing arguments: {err}");
        process::exit(1);
    });

    // --snip--

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    let contents = fs::read_to_string(config.file_path)
        .expect("Should have been able to read the file");

    println!("With text:\n{contents}");
}

struct Config {
    query: String,
    file_path: String,
}

impl Config {
    fn build(args: &[String]) -> Result<Config, &'static str> {
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let file_path = args[2].clone();

        Ok(Config { query, file_path })
    }
}

清单 12-10：如果构建 Config 失败，则退出并返回错误代码

在这个清单中，我们使用了一个尚未详细介绍的方法：unwrap_or_else，它是由标准库在 Result<T, E> 上定义的。使用 unwrap_or_else 允许我们定义一些自定义的、非 panic! 的错误处理。如果 Result 是一个 Ok 值，则此方法的行为类似于 unwrap：它返回 Ok 包装的内部值。但是，如果该值是一个 Err 值，则此方法会调用*闭包*中的代码，这是一个我们定义的匿名函数，并作为参数传递给 unwrap_or_else。我们将在第 13 章中更详细地介绍闭包。目前，您只需要知道 unwrap_or_else 会将 Err 的内部值（在本例中是我们添加在清单 12-9 中的静态字符串 "参数不足"）传递给出现在竖线之间的参数 err 中的闭包。然后，闭包中的代码可以在运行时使用 err 值。

我们添加了一个新的 use 行，将 process 从标准库引入作用域。将在错误情况下运行的闭包中的代码只有两行：我们打印 err 值，然后调用 process::exit。process::exit 函数将立即停止程序，并返回作为退出状态代码传递的数字。这类似于我们在清单 12-8 中使用的基于 panic! 的处理，但我们不再获得所有额外的输出。让我们试试看

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

太棒了！此输出对我们的用户来说更加友好。

从 `main` 中提取逻辑

现在我们已经完成了配置解析的重构，让我们转向程序的逻辑。正如我们在“二进制项目的关注点分离”中所述，我们将提取一个名为 run 的函数，该函数将包含当前 main 函数中所有与设置配置或处理错误无关的逻辑。完成后，main 将变得简洁，并且易于通过检查进行验证，并且我们将能够为所有其他逻辑编写测试。

清单 12-11 显示了提取的 run 函数。目前，我们只是进行了一些小的、渐进式的改进，即提取函数。我们仍在*src/main.rs*中定义函数。

文件名：src/main.rs

use std::env;
use std::fs;
use std::process;

fn main() {
    // --snip--

    let args: Vec<String> = env::args().collect();

    let config = Config::build(&args).unwrap_or_else(|err| {
        println!("Problem parsing arguments: {err}");
        process::exit(1);
    });

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    run(config);
}

fn run(config: Config) {
    let contents = fs::read_to_string(config.file_path)
        .expect("Should have been able to read the file");

    println!("With text:\n{contents}");
}

// --snip--

struct Config {
    query: String,
    file_path: String,
}

impl Config {
    fn build(args: &[String]) -> Result<Config, &'static str> {
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let file_path = args[2].clone();

        Ok(Config { query, file_path })
    }
}

清单 12-11：提取包含程序其余逻辑的 run 函数

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

从 `run` 函数返回错误

将剩余的程序逻辑分离到 run 函数后，我们可以像在清单 12-9 中对 Config::build 所做的那样改进错误处理。run 函数将返回一个 Result<T, E>，而不是允许程序通过调用 expect 来 panic。这将让我们能够以用户友好的方式进一步将处理错误的逻辑整合到 main 中。清单 12-12 显示了我们需要对 run 的签名和主体进行的更改。

文件名：src/main.rs

use std::env;
use std::fs;
use std::process;
use std::error::Error;

// --snip--


fn main() {
    let args: Vec<String> = env::args().collect();

    let config = Config::build(&args).unwrap_or_else(|err| {
        println!("Problem parsing arguments: {err}");
        process::exit(1);
    });

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    run(config);
}

fn run(config: Config) -> Result<(), Box<dyn Error>> {
    let contents = fs::read_to_string(config.file_path)?;

    println!("With text:\n{contents}");

    Ok(())
}

struct Config {
    query: String,
    file_path: String,
}

impl Config {
    fn build(args: &[String]) -> Result<Config, &'static str> {
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let file_path = args[2].clone();

        Ok(Config { query, file_path })
    }
}

清单 12-12：更改 run 函数以返回 Result

我们在这里做了三个重大改变。首先，我们将 run 函数的返回类型更改为 Result<(), Box<dyn Error>>。此函数以前返回单元类型 ()，我们在 Ok 情况下将其保留为返回值。

对于错误类型，我们使用了*特征对象* Box<dyn Error>（我们已经使用顶部的 use 语句将 std::error::Error 引入作用域）。我们将在第 17 章中介绍特征对象。目前，您只需要知道 Box<dyn Error> 意味着该函数将返回一个实现 Error 特征的类型，但我们不必指定返回值的具体类型。这为我们提供了灵活性，可以返回在不同错误情况下可能具有不同类型的错误值。dyn 关键字是“动态”的缩写。

其次，我们删除了对 expect 的调用，转而使用 ? 运算符，正如我们在第 9 章中讨论的那样。? 不会在出错时 panic!，而是会从当前函数返回错误值，以便调用者处理。

第三，run 函数现在在成功的情况下返回一个 Ok 值。我们在签名中将 run 函数的成功类型声明为 ()，这意味着我们需要将单元类型值包装在 Ok 值中。这种 Ok(()) 语法乍一看可能有点奇怪，但像这样使用 () 是表明我们调用 run 只是为了它的副作用的惯用方式；它不会返回我们需要的值。

当您运行此代码时，它将编译但会显示警告

$ cargo run -- the poem.txt
   Compiling minigrep v0.1.0 (file:///projects/minigrep)
warning: unused `Result` that must be used
  --> src/main.rs:19:5
   |
19 |     run(config);
   |     ^^^^^^^^^^^
   |
   = note: this `Result` may be an `Err` variant, which should be handled
   = note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
   |
19 |     let _ = run(config);
   |     +++++++

warning: `minigrep` (bin "minigrep") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.71s
     Running `target/debug/minigrep the poem.txt`
Searching for the
In file poem.txt
With text:
I'm nobody! Who are you?
Are you nobody, too?
Then there's a pair of us - don't tell!
They'd banish us, you know.

How dreary to be somebody!
How public, like a frog
To tell your name the livelong day
To an admiring bog!

Rust 告诉我们，我们的代码忽略了 Result 值，并且 Result 值可能表明发生了错误。但是我们没有检查是否发生了错误，编译器提醒我们，我们可能打算在这里添加一些错误处理代码！现在让我们来纠正这个问题。

在 `main` 中处理从 `run` 返回的错误

我们将使用与清单 12-10 中 Config::build 使用的技术类似的技术来检查错误并处理它们，但略有不同

文件名：src/main.rs

use std::env;
use std::error::Error;
use std::fs;
use std::process;

fn main() {
    // --snip--

    let args: Vec<String> = env::args().collect();

    let config = Config::build(&args).unwrap_or_else(|err| {
        println!("Problem parsing arguments: {err}");
        process::exit(1);
    });

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    if let Err(e) = run(config) {
        println!("Application error: {e}");
        process::exit(1);
    }
}

fn run(config: Config) -> Result<(), Box<dyn Error>> {
    let contents = fs::read_to_string(config.file_path)?;

    println!("With text:\n{contents}");

    Ok(())
}

struct Config {
    query: String,
    file_path: String,
}

impl Config {
    fn build(args: &[String]) -> Result<Config, &'static str> {
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let file_path = args[2].clone();

        Ok(Config { query, file_path })
    }
}

我们使用 if let 而不是 unwrap_or_else 来检查 run 是否返回 Err 值，如果是，则调用 process::exit(1)。run 函数不会像 Config::build 返回 Config 实例那样返回我们想要 unwrap 的值。因为 run 在成功的情况下返回 ()，所以我们只关心检测错误，因此我们不需要 unwrap_or_else 来返回解包后的值，因为它只是 ()。

if let 和 unwrap_or_else 函数的主体在两种情况下都是相同的：我们打印错误并退出。

将代码拆分为库 Crate

到目前为止，我们的 minigrep 项目看起来不错！现在，我们将拆分 src/main.rs 文件，并将一些代码放入 src/lib.rs 文件中。这样，我们就可以测试代码，并使 src/main.rs 文件的职责更少。

让我们将所有不是 main 函数的代码从 src/main.rs 移动到 src/lib.rs

run 函数定义
相关的 use 语句
Config 的定义
Config::build 函数定义

src/lib.rs 的内容应具有清单 12-13 中所示的签名（为了简洁起见，我们省略了函数体）。请注意，在我们修改清单 12-14 中的 src/main.rs 之前，这不会编译。

文件名：src/lib.rs

use std::error::Error;
use std::fs;

pub struct Config {
    pub query: String,
    pub file_path: String,
}

impl Config {
    pub fn build(args: &[String]) -> Result<Config, &'static str> {
        // --snip--
        if args.len() < 3 {
            return Err("not enough arguments");
        }

        let query = args[1].clone();
        let file_path = args[2].clone();

        Ok(Config { query, file_path })
    }
}

pub fn run(config: Config) -> Result<(), Box<dyn Error>> {
    // --snip--
    let contents = fs::read_to_string(config.file_path)?;

    println!("With text:\n{contents}");

    Ok(())
}

清单 12-13：将 Config 和 run 移动到 src/lib.rs

我们大量使用了 pub 关键字：在 Config 上、在其字段及其 build 方法上，以及在 run 函数上。我们现在有了一个具有公共 API 的库 crate，我们可以对其进行测试！

现在，我们需要将移动到 src/lib.rs 的代码引入 src/main.rs 中的二进制 crate 的作用域，如清单 12-14 所示。

文件名：src/main.rs

use std::env;
use std::process;

use minigrep::Config;

fn main() {
    // --snip--
    let args: Vec<String> = env::args().collect();

    let config = Config::build(&args).unwrap_or_else(|err| {
        println!("Problem parsing arguments: {err}");
        process::exit(1);
    });

    println!("Searching for {}", config.query);
    println!("In file {}", config.file_path);

    if let Err(e) = minigrep::run(config) {
        // --snip--
        println!("Application error: {e}");
        process::exit(1);
    }
}

清单 12-14：在 src/main.rs 中使用 minigrep 库 crate

我们添加了一个 use minigrep::Config 行，将 Config 类型从库 crate 引入二进制 crate 的作用域，并为 run 函数添加了 crate 名称前缀。现在，所有功能都应该连接起来并正常工作。使用 cargo run 运行程序，并确保一切正常。

呼！这真是费了不少功夫，但我们已经为未来的成功做好了准备。现在，处理错误变得容易多了，而且我们也使代码更加模块化了。从现在开始，我们几乎所有的工作都将在 src/lib.rs 中完成。

让我们利用这种新发现的模块化来做一些用旧代码很难做到的事情，而用新代码却很容易做到的事情：我们将编写一些测试！

Rust 程序设计语言

二进制项目的关注点分离

提取参数解析器

对配置值进行分组

使用 `clone` 的权衡

为 `Config` 创建构造函数

修复错误处理

改进错误消息

返回 `Result` 而不是调用 `panic!`

调用 `Config::build` 并处理错误

从 `main` 中提取逻辑

从 `run` 函数返回错误

在 `main` 中处理从 `run` 返回的错误

将代码拆分为库 Crate