RustBook/ch12-03-improving-error-handling-and-modularity.html

778 lines
58 KiB
HTML
Raw Normal View History

2020-01-06 20:57:15 +00:00
<!DOCTYPE HTML>
<html lang="en" class="sidebar-visible no-js light">
<head>
<!-- Book generated using mdBook -->
<meta charset="UTF-8">
<title>Refactoring to Improve Modularity and Error Handling - The Rust Programming Language</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#ffffff" />
<link rel="shortcut icon" href="favicon.png">
<link rel="stylesheet" href="css/variables.css">
<link rel="stylesheet" href="css/general.css">
<link rel="stylesheet" href="css/chrome.css">
<link rel="stylesheet" href="css/print.css" media="print">
<!-- Fonts -->
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
<link href="googleFonts/css.css" rel="stylesheet" type="text/css">
<!-- Highlight.js Stylesheets -->
<link rel="stylesheet" href="highlight.css">
<link rel="stylesheet" href="tomorrow-night.css">
<link rel="stylesheet" href="ayu-highlight.css">
<!-- Custom theme stylesheets -->
<link rel="stylesheet" href="ferris.css">
<link rel="stylesheet" href="theme/2018-edition.css">
</head>
<body>
<!-- Provide site root to javascript -->
<script type="text/javascript">
var path_to_root = "";
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "light" : "light";
</script>
<!-- Work around some values being stored in localStorage wrapped in quotes -->
<script type="text/javascript">
try {
var theme = localStorage.getItem('mdbook-theme');
var sidebar = localStorage.getItem('mdbook-sidebar');
if (theme.startsWith('"') && theme.endsWith('"')) {
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
}
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
}
} catch (e) { }
</script>
<!-- Set the theme before any content is loaded, prevents flash -->
<script type="text/javascript">
var theme;
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
if (theme === null || theme === undefined) { theme = default_theme; }
var html = document.querySelector('html');
html.classList.remove('no-js')
html.classList.remove('light')
html.classList.add(theme);
html.classList.add('js');
</script>
<!-- Hide / unhide sidebar before it is displayed -->
<script type="text/javascript">
var html = document.querySelector('html');
var sidebar = 'hidden';
if (document.body.clientWidth >= 1080) {
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
sidebar = sidebar || 'visible';
}
html.classList.remove('sidebar-visible');
html.classList.add("sidebar-" + sidebar);
</script>
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
<div id="sidebar-scrollbox" class="sidebar-scrollbox">
<ol class="chapter"><li class="expanded affix "><a href="title-page.html">The Rust Programming Language</a></li><li class="expanded affix "><a href="foreword.html">Foreword</a></li><li class="expanded affix "><a href="ch00-00-introduction.html">Introduction</a></li><li class="expanded "><a href="ch01-00-getting-started.html"><strong aria-hidden="true">1.</strong> Getting Started</a></li><li><ol class="section"><li class="expanded "><a href="ch01-01-installation.html"><strong aria-hidden="true">1.1.</strong> Installation</a></li><li class="expanded "><a href="ch01-02-hello-world.html"><strong aria-hidden="true">1.2.</strong> Hello, World!</a></li><li class="expanded "><a href="ch01-03-hello-cargo.html"><strong aria-hidden="true">1.3.</strong> Hello, Cargo!</a></li></ol></li><li class="expanded "><a href="ch02-00-guessing-game-tutorial.html"><strong aria-hidden="true">2.</strong> Programming a Guessing Game</a></li><li class="expanded "><a href="ch03-00-common-programming-concepts.html"><strong aria-hidden="true">3.</strong> Common Programming Concepts</a></li><li><ol class="section"><li class="expanded "><a href="ch03-01-variables-and-mutability.html"><strong aria-hidden="true">3.1.</strong> Variables and Mutability</a></li><li class="expanded "><a href="ch03-02-data-types.html"><strong aria-hidden="true">3.2.</strong> Data Types</a></li><li class="expanded "><a href="ch03-03-how-functions-work.html"><strong aria-hidden="true">3.3.</strong> Functions</a></li><li class="expanded "><a href="ch03-04-comments.html"><strong aria-hidden="true">3.4.</strong> Comments</a></li><li class="expanded "><a href="ch03-05-control-flow.html"><strong aria-hidden="true">3.5.</strong> Control Flow</a></li></ol></li><li class="expanded "><a href="ch04-00-understanding-ownership.html"><strong aria-hidden="true">4.</strong> Understanding Ownership</a></li><li><ol class="section"><li class="expanded "><a href="ch04-01-what-is-ownership.html"><strong aria-hidden="true">4.1.</strong> What is Ownership?</a></li><li class="expanded "><a href="ch04-02-references-and-borrowing.html"><strong aria-hidden="true">4.2.</strong> References and Borrowing</a></li><li class="expanded "><a href="ch04-03-slices.html"><strong aria-hidden="true">4.3.</strong> The Slice Type</a></li></ol></li><li class="expanded "><a href="ch05-00-structs.html"><strong aria-hidden="true">5.</strong> Using Structs to Structure Related Data</a></li><li><ol class="section"><li class="expanded "><a href="ch05-01-defining-structs.html"><strong aria-hidden="true">5.1.</strong> Defining and Instantiating Structs</a></li><li class="expanded "><a href="ch05-02-example-structs.html"><strong aria-hidden="true">5.2.</strong> An Example Program Using Structs</a></li><li class="expanded "><a href="ch05-03-method-syntax.html"><strong aria-hidden="true">5.3.</strong> Method Syntax</a></li></ol></li><li class="expanded "><a href="ch06-00-enums.html"><strong aria-hidden="true">6.</strong> Enums and Pattern Matching</a></li><li><ol class="section"><li class="expanded "><a href="ch06-01-defining-an-enum.html"><strong aria-hidden="true">6.1.</strong> Defining an Enum</a></li><li class="expanded "><a href="ch06-02-match.html"><strong aria-hidden="true">6.2.</strong> The match Control Flow Operator</a></li><li class="expanded "><a href="ch06-03-if-let.html"><strong aria-hidden="true">6.3.</strong> Concise Control Flow with if let</a></li></ol></li><li class="expanded "><a href="ch07-00-managing-growing-projects-with-packages-crates-and-modules.html"><strong aria-hidden="true">7.</strong> Managing Growing Projects with Packages, Crates, and Modules</a></li><li><ol class="section"><li class="expanded "><a href="ch07-01-packages-and-crates.html"><strong aria-hidden="true">7.1.</strong> Packages and Crates</a></li><li class="expanded "><a href="ch07-02-defining-modules-to-control-scope-and-privacy.html"><strong aria-hidden="true">7.2.</strong> Defining Modules to Control Scope and Privacy</a></li><li class="expanded "><a href="ch07-03-paths-for-referring-to-an-item-in-the-module-tree.html"><
</div>
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
</nav>
<div id="page-wrapper" class="page-wrapper">
<div class="page">
<div id="menu-bar" class="menu-bar">
<div id="menu-bar-sticky-container">
<div class="left-buttons">
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
<i class="fa fa-bars"></i>
</button>
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
<i class="fa fa-paint-brush"></i>
</button>
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
</ul>
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
<i class="fa fa-search"></i>
</button>
</div>
<h1 class="menu-title">The Rust Programming Language</h1>
<div class="right-buttons">
<a href="print.html" title="Print this book" aria-label="Print this book">
<i id="print-button" class="fa fa-print"></i>
</a>
</div>
</div>
</div>
<div id="search-wrapper" class="hidden">
<form id="searchbar-outer" class="searchbar-outer">
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
</form>
<div id="searchresults-outer" class="searchresults-outer hidden">
<div id="searchresults-header" class="searchresults-header"></div>
<ul id="searchresults">
</ul>
</div>
</div>
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
<script type="text/javascript">
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
});
</script>
<div id="content" class="content">
<main>
<h2><a class="header" href="#refactoring-to-improve-modularity-and-error-handling" id="refactoring-to-improve-modularity-and-error-handling">Refactoring to Improve Modularity and Error Handling</a></h2>
<p>To improve our program, well fix four problems that have to do with the
programs structure and how its handling potential errors.</p>
<p>First, our <code>main</code> function now performs two tasks: it parses arguments and
reads files. For such a small function, this isnt a major problem. However, if
we continue to grow our program inside <code>main</code>, the number of separate tasks the
<code>main</code> function handles will increase. As a function gains responsibilities, it
becomes more difficult to reason about, harder to test, and harder to change
without breaking one of its parts. Its best to separate functionality so each
function is responsible for one task.</p>
<p>This issue also ties into the second problem: although <code>query</code> and <code>filename</code>
are configuration variables to our program, variables like <code>contents</code> are used
to perform the programs logic. The longer <code>main</code> becomes, the more variables
well need to bring into scope; the more variables we have in scope, the harder
it will be to keep track of the purpose of each. Its best to group the
configuration variables into one structure to make their purpose clear.</p>
<p>The third problem is that weve used <code>expect</code> to print an error message when
reading the file fails, but the error message just prints <code>Something went wrong reading the file</code>. Reading a file can fail in a number of ways: for example,
the file could be missing, or we might not have permission to open it. Right
now, regardless of the situation, wed print the <code>Something went wrong reading the file</code> error message, which wouldnt give the user any information!</p>
<p>Fourth, we use <code>expect</code> repeatedly to handle different errors, and if the user
runs our program without specifying enough arguments, theyll get an <code>index out of bounds</code> error from Rust that doesnt clearly explain the problem. It would
be best if all the error-handling code were in one place so future maintainers
had only one place to consult in the code if the error-handling logic needed to
change. Having all the error-handling code in one place will also ensure that
were printing messages that will be meaningful to our end users.</p>
<p>Lets address these four problems by refactoring our project.</p>
<h3><a class="header" href="#separation-of-concerns-for-binary-projects" id="separation-of-concerns-for-binary-projects">Separation of Concerns for Binary Projects</a></h3>
<p>The organizational problem of allocating responsibility for multiple tasks to
the <code>main</code> function is common to many binary projects. As a result, the Rust
community has developed a process to use as a guideline for splitting the
separate concerns of a binary program when <code>main</code> starts getting large. The
process has the following steps:</p>
<ul>
<li>Split your program into a <em>main.rs</em> and a <em>lib.rs</em> and move your programs
logic to <em>lib.rs</em>.</li>
<li>As long as your command line parsing logic is small, it can remain in
<em>main.rs</em>.</li>
<li>When the command line parsing logic starts getting complicated, extract it
from <em>main.rs</em> and move it to <em>lib.rs</em>.</li>
</ul>
<p>The responsibilities that remain in the <code>main</code> function after this process
should be limited to the following:</p>
<ul>
<li>Calling the command line parsing logic with the argument values</li>
<li>Setting up any other configuration</li>
<li>Calling a <code>run</code> function in <em>lib.rs</em></li>
<li>Handling the error if <code>run</code> returns an error</li>
</ul>
<p>This pattern is about separating concerns: <em>main.rs</em> handles running the
program, and <em>lib.rs</em> handles all the logic of the task at hand. Because you
cant test the <code>main</code> function directly, this structure lets you test all of
your programs logic by moving it into functions in <em>lib.rs</em>. The only code
that remains in <em>main.rs</em> will be small enough to verify its correctness by
reading it. Lets rework our program by following this process.</p>
<h4><a class="header" href="#extracting-the-argument-parser" id="extracting-the-argument-parser">Extracting the Argument Parser</a></h4>
<p>Well extract the functionality for parsing arguments into a function that
<code>main</code> will call to prepare for moving the command line parsing logic to
<em>src/lib.rs</em>. Listing 12-5 shows the new start of <code>main</code> that calls a new
function <code>parse_config</code>, which well define in <em>src/main.rs</em> for the moment.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">fn main() {
let args: Vec&lt;String&gt; = env::args().collect();
let (query, filename) = parse_config(&amp;args);
// --snip--
}
fn parse_config(args: &amp;[String]) -&gt; (&amp;str, &amp;str) {
let query = &amp;args[1];
let filename = &amp;args[2];
(query, filename)
}
</code></pre>
<p><span class="caption">Listing 12-5: Extracting a <code>parse_config</code> function from
<code>main</code></span></p>
<p>Were still collecting the command line arguments into a vector, but instead of
assigning the argument value at index 1 to the variable <code>query</code> and the
argument value at index 2 to the variable <code>filename</code> within the <code>main</code>
function, we pass the whole vector to the <code>parse_config</code> function. The
<code>parse_config</code> function then holds the logic that determines which argument
goes in which variable and passes the values back to <code>main</code>. We still create
the <code>query</code> and <code>filename</code> variables in <code>main</code>, but <code>main</code> no longer has the
responsibility of determining how the command line arguments and variables
correspond.</p>
<p>This rework may seem like overkill for our small program, but were refactoring
in small, incremental steps. After making this change, run the program again to
verify that the argument parsing still works. Its good to check your progress
often, to help identify the cause of problems when they occur.</p>
<h4><a class="header" href="#grouping-configuration-values" id="grouping-configuration-values">Grouping Configuration Values</a></h4>
<p>We can take another small step to improve the <code>parse_config</code> function further.
At the moment, were returning a tuple, but then we immediately break that
tuple into individual parts again. This is a sign that perhaps we dont have
the right abstraction yet.</p>
<p>Another indicator that shows theres room for improvement is the <code>config</code> part
of <code>parse_config</code>, which implies that the two values we return are related and
are both part of one configuration value. Were not currently conveying this
meaning in the structure of the data other than by grouping the two values into
a tuple; we could put the two values into one struct and give each of the
struct fields a meaningful name. Doing so will make it easier for future
maintainers of this code to understand how the different values relate to each
other and what their purpose is.</p>
<blockquote>
<p>Note: Using primitive values when a complex type would be more appropriate is
an anti-pattern known as <em>primitive obsession</em>.</p>
</blockquote>
<p>Listing 12-6 shows the improvements to the <code>parse_config</code> function.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust should_panic"><span class="boring">use std::env;
</span><span class="boring">use std::fs;
</span><span class="boring">
</span>fn main() {
let args: Vec&lt;String&gt; = env::args().collect();
let config = parse_config(&amp;args);
println!(&quot;Searching for {}&quot;, config.query);
println!(&quot;In file {}&quot;, config.filename);
let contents = fs::read_to_string(config.filename)
.expect(&quot;Something went wrong reading the file&quot;);
// --snip--
}
struct Config {
query: String,
filename: String,
}
fn parse_config(args: &amp;[String]) -&gt; Config {
let query = args[1].clone();
let filename = args[2].clone();
Config { query, filename }
}
</code></pre></pre>
<p><span class="caption">Listing 12-6: Refactoring <code>parse_config</code> to return an
instance of a <code>Config</code> struct</span></p>
<p>Weve added a struct named <code>Config</code> defined to have fields named <code>query</code> and
<code>filename</code>. The signature of <code>parse_config</code> now indicates that it returns a
<code>Config</code> value. In the body of <code>parse_config</code>, where we used to return string
slices that reference <code>String</code> values in <code>args</code>, we now define <code>Config</code> to
contain owned <code>String</code> values. The <code>args</code> variable in <code>main</code> is the owner of
the argument values and is only letting the <code>parse_config</code> function borrow
them, which means wed violate Rusts borrowing rules if <code>Config</code> tried to take
ownership of the values in <code>args</code>.</p>
<p>We could manage the <code>String</code> data in a number of different ways, but the
easiest, though somewhat inefficient, route is to call the <code>clone</code> method on
the values. This will make a full copy of the data for the <code>Config</code> instance to
own, which takes more time and memory than storing a reference to the string
data. However, cloning the data also makes our code very straightforward
because we dont have to manage the lifetimes of the references; in this
circumstance, giving up a little performance to gain simplicity is a worthwhile
trade-off.</p>
<blockquote>
<h3><a class="header" href="#the-trade-offs-of-using-clone" id="the-trade-offs-of-using-clone">The Trade-Offs of Using <code>clone</code></a></h3>
<p>Theres a tendency among many Rustaceans to avoid using <code>clone</code> to fix
ownership problems because of its runtime cost. In
<a href="ch13-00-functional-features.html">Chapter 13</a><!-- ignore -->, youll learn how to use more efficient
methods in this type of situation. But for now, its okay to copy a few
strings to continue making progress because youll make these copies only
once and your filename and query string are very small. Its better to have
a working program thats a bit inefficient than to try to hyperoptimize code
on your first pass. As you become more experienced with Rust, itll be
easier to start with the most efficient solution, but for now, its
perfectly acceptable to call <code>clone</code>.</p>
</blockquote>
<p>Weve updated <code>main</code> so it places the instance of <code>Config</code> returned by
<code>parse_config</code> into a variable named <code>config</code>, and we updated the code that
previously used the separate <code>query</code> and <code>filename</code> variables so it now uses
the fields on the <code>Config</code> struct instead.</p>
<p>Now our code more clearly conveys that <code>query</code> and <code>filename</code> are related and
that their purpose is to configure how the program will work. Any code that
uses these values knows to find them in the <code>config</code> instance in the fields
named for their purpose.</p>
<h4><a class="header" href="#creating-a-constructor-for-config" id="creating-a-constructor-for-config">Creating a Constructor for <code>Config</code></a></h4>
<p>So far, weve extracted the logic responsible for parsing the command line
arguments from <code>main</code> and placed it in the <code>parse_config</code> function. Doing so
helped us to see that the <code>query</code> and <code>filename</code> values were related and that
relationship should be conveyed in our code. We then added a <code>Config</code> struct to
name the related purpose of <code>query</code> and <code>filename</code> and to be able to return the
values names as struct field names from the <code>parse_config</code> function.</p>
<p>So now that the purpose of the <code>parse_config</code> function is to create a <code>Config</code>
instance, we can change <code>parse_config</code> from a plain function to a function
named <code>new</code> that is associated with the <code>Config</code> struct. Making this change
will make the code more idiomatic. We can create instances of types in the
standard library, such as <code>String</code>, by calling <code>String::new</code>. Similarly, by
changing <code>parse_config</code> into a <code>new</code> function associated with <code>Config</code>, well
be able to create instances of <code>Config</code> by calling <code>Config::new</code>. Listing 12-7
shows the changes we need to make.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust should_panic"><span class="boring">use std::env;
</span><span class="boring">
</span>fn main() {
let args: Vec&lt;String&gt; = env::args().collect();
let config = Config::new(&amp;args);
// --snip--
}
<span class="boring">struct Config {
</span><span class="boring"> query: String,
</span><span class="boring"> filename: String,
</span><span class="boring">}
</span><span class="boring">
</span>// --snip--
impl Config {
fn new(args: &amp;[String]) -&gt; Config {
let query = args[1].clone();
let filename = args[2].clone();
Config { query, filename }
}
}
</code></pre></pre>
<p><span class="caption">Listing 12-7: Changing <code>parse_config</code> into
<code>Config::new</code></span></p>
<p>Weve updated <code>main</code> where we were calling <code>parse_config</code> to instead call
<code>Config::new</code>. Weve changed the name of <code>parse_config</code> to <code>new</code> and moved it
within an <code>impl</code> block, which associates the <code>new</code> function with <code>Config</code>. Try
compiling this code again to make sure it works.</p>
<h3><a class="header" href="#fixing-the-error-handling" id="fixing-the-error-handling">Fixing the Error Handling</a></h3>
<p>Now well work on fixing our error handling. Recall that attempting to access
the values in the <code>args</code> vector at index 1 or index 2 will cause the program to
panic if the vector contains fewer than three items. Try running the program
without any arguments; it will look like this:</p>
<pre><code class="language-text">$ cargo run
Compiling minigrep v0.1.0 (file:///projects/minigrep)
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/minigrep`
thread 'main' panicked at 'index out of bounds: the len is 1
but the index is 1', src/main.rs:25:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.
</code></pre>
<p>The line <code>index out of bounds: the len is 1 but the index is 1</code> is an error
message intended for programmers. It wont help our end users understand what
happened and what they should do instead. Lets fix that now.</p>
<h4><a class="header" href="#improving-the-error-message" id="improving-the-error-message">Improving the Error Message</a></h4>
<p>In Listing 12-8, we add a check in the <code>new</code> function that will verify that the
slice is long enough before accessing index 1 and 2. If the slice isnt long
enough, the program panics and displays a better error message than the <code>index out of bounds</code> message.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">// --snip--
fn new(args: &amp;[String]) -&gt; Config {
if args.len() &lt; 3 {
panic!(&quot;not enough arguments&quot;);
}
// --snip--
</code></pre>
<p><span class="caption">Listing 12-8: Adding a check for the number of
arguments</span></p>
<p>This code is similar to <a href="ch09-03-to-panic-or-not-to-panic.html#creating-custom-types-for-validation">the <code>Guess::new</code> function we wrote in Listing
9-10</a><!-- ignore -->, where we called <code>panic!</code> when the
<code>value</code> argument was out of the range of valid values. Instead of checking for
a range of values here, were checking that the length of <code>args</code> is at least 3
and the rest of the function can operate under the assumption that this
condition has been met. If <code>args</code> has fewer than three items, this condition
will be true, and we call the <code>panic!</code> macro to end the program immediately.</p>
<p>With these extra few lines of code in <code>new</code>, lets run the program without any
arguments again to see what the error looks like now:</p>
<pre><code class="language-text">$ cargo run
Compiling minigrep v0.1.0 (file:///projects/minigrep)
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/minigrep`
thread 'main' panicked at 'not enough arguments', src/main.rs:26:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
</code></pre>
<p>This output is better: we now have a reasonable error message. However, we also
have extraneous information we dont want to give to our users. Perhaps using
the technique we used in Listing 9-10 isnt the best to use here: a call to
<code>panic!</code> is more appropriate for a programming problem than a usage problem,
<a href="ch09-03-to-panic-or-not-to-panic.html#guidelines-for-error-handling">as discussed in Chapter 9</a><!-- ignore -->. Instead, we
can use the other technique you learned about in Chapter 9—<a href="ch09-02-recoverable-errors-with-result.html">returning a
<code>Result</code></a><!-- ignore --> that indicates either success or an error.</p>
<h4><a class="header" href="#returning-a-result-from-new-instead-of-calling-panic" id="returning-a-result-from-new-instead-of-calling-panic">Returning a <code>Result</code> from <code>new</code> Instead of Calling <code>panic!</code></a></h4>
<p>We can instead return a <code>Result</code> value that will contain a <code>Config</code> instance in
the successful case and will describe the problem in the error case. When
<code>Config::new</code> is communicating to <code>main</code>, we can use the <code>Result</code> type to
signal there was a problem. Then we can change <code>main</code> to convert an <code>Err</code>
variant into a more practical error for our users without the surrounding text
about <code>thread 'main'</code> and <code>RUST_BACKTRACE</code> that a call to <code>panic!</code> causes.</p>
<p>Listing 12-9 shows the changes we need to make to the return value of
<code>Config::new</code> and the body of the function needed to return a <code>Result</code>. Note
that this wont compile until we update <code>main</code> as well, which well do in the
next listing.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">impl Config {
fn new(args: &amp;[String]) -&gt; Result&lt;Config, &amp;'static str&gt; {
if args.len() &lt; 3 {
return Err(&quot;not enough arguments&quot;);
}
let query = args[1].clone();
let filename = args[2].clone();
Ok(Config { query, filename })
}
}
</code></pre>
<p><span class="caption">Listing 12-9: Returning a <code>Result</code> from
<code>Config::new</code></span></p>
<p>Our <code>new</code> function now returns a <code>Result</code> with a <code>Config</code> instance in the
success case and a <code>&amp;'static str</code> in the error case. Recall from <a href="ch10-03-lifetime-syntax.html#the-static-lifetime">“The Static
Lifetime”</a><!-- ignore --> section in Chapter 10 that
<code>&amp;'static str</code> is the type of string literals, which is our error message type
for now.</p>
<p>Weve made two changes in the body of the <code>new</code> function: instead of calling
<code>panic!</code> when the user doesnt pass enough arguments, we now return an <code>Err</code>
value, and weve wrapped the <code>Config</code> return value in an <code>Ok</code>. These changes
make the function conform to its new type signature.</p>
<p>Returning an <code>Err</code> value from <code>Config::new</code> allows the <code>main</code> function to
handle the <code>Result</code> value returned from the <code>new</code> function and exit the process
more cleanly in the error case.</p>
<h4><a class="header" href="#calling-confignew-and-handling-errors" id="calling-confignew-and-handling-errors">Calling <code>Config::new</code> and Handling Errors</a></h4>
<p>To handle the error case and print a user-friendly message, we need to update
<code>main</code> to handle the <code>Result</code> being returned by <code>Config::new</code>, as shown in
Listing 12-10. Well also take the responsibility of exiting the command line
tool with a nonzero error code from <code>panic!</code> and implement it by hand. A
nonzero exit status is a convention to signal to the process that called our
program that the program exited with an error state.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">use std::process;
fn main() {
let args: Vec&lt;String&gt; = env::args().collect();
let config = Config::new(&amp;args).unwrap_or_else(|err| {
println!(&quot;Problem parsing arguments: {}&quot;, err);
process::exit(1);
});
// --snip--
</code></pre>
<p><span class="caption">Listing 12-10: Exiting with an error code if creating a
new <code>Config</code> fails</span></p>
<p>In this listing, weve used a method we havent covered before:
<code>unwrap_or_else</code>, which is defined on <code>Result&lt;T, E&gt;</code> by the standard library.
Using <code>unwrap_or_else</code> allows us to define some custom, non-<code>panic!</code> error
handling. If the <code>Result</code> is an <code>Ok</code> value, this methods behavior is similar
to <code>unwrap</code>: it returns the inner value <code>Ok</code> is wrapping. However, if the value
is an <code>Err</code> value, this method calls the code in the <em>closure</em>, which is an
anonymous function we define and pass as an argument to <code>unwrap_or_else</code>. Well
cover closures in more detail in <a href="ch13-00-functional-features.html">Chapter 13</a><!-- ignore -->. For now,
you just need to know that <code>unwrap_or_else</code> will pass the inner value of the
<code>Err</code>, which in this case is the static string <code>not enough arguments</code> that we
added in Listing 12-9, to our closure in the argument <code>err</code> that appears
between the vertical pipes. The code in the closure can then use the <code>err</code>
value when it runs.</p>
<p>Weve added a new <code>use</code> line to bring <code>process</code> from the standard library into
scope. The code in the closure that will be run in the error case is only two
lines: we print the <code>err</code> value and then call <code>process::exit</code>. The
<code>process::exit</code> function will stop the program immediately and return the
number that was passed as the exit status code. This is similar to the
<code>panic!</code>-based handling we used in Listing 12-8, but we no longer get all the
extra output. Lets try it:</p>
<pre><code class="language-text">$ cargo run
Compiling minigrep v0.1.0 (file:///projects/minigrep)
Finished dev [unoptimized + debuginfo] target(s) in 0.48 secs
Running `target/debug/minigrep`
Problem parsing arguments: not enough arguments
</code></pre>
<p>Great! This output is much friendlier for our users.</p>
<h3><a class="header" href="#extracting-logic-from-main" id="extracting-logic-from-main">Extracting Logic from <code>main</code></a></h3>
<p>Now that weve finished refactoring the configuration parsing, lets turn to
the programs logic. As we stated in <a href="#separation-of-concerns-for-binary-projects">“Separation of Concerns for Binary
Projects”</a><!-- ignore -->, well
extract a function named <code>run</code> that will hold all the logic currently in the
<code>main</code> function that isnt involved with setting up configuration or handling
errors. When were done, <code>main</code> will be concise and easy to verify by
inspection, and well be able to write tests for all the other logic.</p>
<p>Listing 12-11 shows the extracted <code>run</code> function. For now, were just making
the small, incremental improvement of extracting the function. Were still
defining the function in <em>src/main.rs</em>.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">fn main() {
// --snip--
println!(&quot;Searching for {}&quot;, config.query);
println!(&quot;In file {}&quot;, config.filename);
run(config);
}
fn run(config: Config) {
let contents = fs::read_to_string(config.filename)
.expect(&quot;Something went wrong reading the file&quot;);
println!(&quot;With text:\n{}&quot;, contents);
}
// --snip--
</code></pre>
<p><span class="caption">Listing 12-11: Extracting a <code>run</code> function containing the
rest of the program logic</span></p>
<p>The <code>run</code> function now contains all the remaining logic from <code>main</code>, starting
from reading the file. The <code>run</code> function takes the <code>Config</code> instance as an
argument.</p>
<h4><a class="header" href="#returning-errors-from-the-run-function" id="returning-errors-from-the-run-function">Returning Errors from the <code>run</code> Function</a></h4>
<p>With the remaining program logic separated into the <code>run</code> function, we can
improve the error handling, as we did with <code>Config::new</code> in Listing 12-9.
Instead of allowing the program to panic by calling <code>expect</code>, the <code>run</code>
function will return a <code>Result&lt;T, E&gt;</code> when something goes wrong. This will let
us further consolidate into <code>main</code> the logic around handling errors in a
user-friendly way. Listing 12-12 shows the changes we need to make to the
signature and body of <code>run</code>.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">use std::error::Error;
// --snip--
fn run(config: Config) -&gt; Result&lt;(), Box&lt;dyn Error&gt;&gt; {
let contents = fs::read_to_string(config.filename)?;
println!(&quot;With text:\n{}&quot;, contents);
Ok(())
}
</code></pre>
<p><span class="caption">Listing 12-12: Changing the <code>run</code> function to return
<code>Result</code></span></p>
<p>Weve made three significant changes here. First, we changed the return type of
the <code>run</code> function to <code>Result&lt;(), Box&lt;dyn Error&gt;&gt;</code>. This function previously
returned the unit type, <code>()</code>, and we keep that as the value returned in the
<code>Ok</code> case.</p>
<p>For the error type, we used the <em>trait object</em> <code>Box&lt;dyn Error&gt;</code> (and weve
brought <code>std::error::Error</code> into scope with a <code>use</code> statement at the top).
Well cover trait objects in <a href="ch17-00-oop.html">Chapter 17</a><!-- ignore -->. For now, just
know that <code>Box&lt;dyn Error&gt;</code> means the function will return a type that
implements the <code>Error</code> trait, but we dont have to specify what particular type
the return value will be. This gives us flexibility to return error values that
may be of different types in different error cases. The <code>dyn</code> keyword is short
for “dynamic.”</p>
<p>Second, weve removed the call to <code>expect</code> in favor of the <code>?</code> operator, as we
talked about in <a href="ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator">Chapter 9</a><!-- ignore -->. Rather than
<code>panic!</code> on an error, <code>?</code> will return the error value from the current function
for the caller to handle.</p>
<p>Third, the <code>run</code> function now returns an <code>Ok</code> value in the success case. Weve
declared the <code>run</code> functions success type as <code>()</code> in the signature, which
means we need to wrap the unit type value in the <code>Ok</code> value. This <code>Ok(())</code>
syntax might look a bit strange at first, but using <code>()</code> like this is the
idiomatic way to indicate that were calling <code>run</code> for its side effects only;
it doesnt return a value we need.</p>
<p>When you run this code, it will compile but will display a warning:</p>
<pre><code class="language-text">warning: unused `std::result::Result` that must be used
--&gt; src/main.rs:17:5
|
17 | run(config);
| ^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: this `Result` may be an `Err` variant, which should be handled
</code></pre>
<p>Rust tells us that our code ignored the <code>Result</code> value and the <code>Result</code> value
might indicate that an error occurred. But were not checking to see whether or
not there was an error, and the compiler reminds us that we probably meant to
have some error-handling code here! Lets rectify that problem now.</p>
<h4><a class="header" href="#handling-errors-returned-from-run-in-main" id="handling-errors-returned-from-run-in-main">Handling Errors Returned from <code>run</code> in <code>main</code></a></h4>
<p>Well check for errors and handle them using a technique similar to one we used
with <code>Config::new</code> in Listing 12-10, but with a slight difference:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">fn main() {
// --snip--
println!(&quot;Searching for {}&quot;, config.query);
println!(&quot;In file {}&quot;, config.filename);
if let Err(e) = run(config) {
println!(&quot;Application error: {}&quot;, e);
process::exit(1);
}
}
</code></pre>
<p>We use <code>if let</code> rather than <code>unwrap_or_else</code> to check whether <code>run</code> returns an
<code>Err</code> value and call <code>process::exit(1)</code> if it does. The <code>run</code> function doesnt
return a value that we want to <code>unwrap</code> in the same way that <code>Config::new</code>
returns the <code>Config</code> instance. Because <code>run</code> returns <code>()</code> in the success case,
we only care about detecting an error, so we dont need <code>unwrap_or_else</code> to
return the unwrapped value because it would only be <code>()</code>.</p>
<p>The bodies of the <code>if let</code> and the <code>unwrap_or_else</code> functions are the same in
both cases: we print the error and exit.</p>
<h3><a class="header" href="#splitting-code-into-a-library-crate" id="splitting-code-into-a-library-crate">Splitting Code into a Library Crate</a></h3>
<p>Our <code>minigrep</code> project is looking good so far! Now well split the
<em>src/main.rs</em> file and put some code into the <em>src/lib.rs</em> file so we can test
it and have a <em>src/main.rs</em> file with fewer responsibilities.</p>
<p>Lets move all the code that isnt the <code>main</code> function from <em>src/main.rs</em> to
<em>src/lib.rs</em>:</p>
<ul>
<li>The <code>run</code> function definition</li>
<li>The relevant <code>use</code> statements</li>
<li>The definition of <code>Config</code></li>
<li>The <code>Config::new</code> function definition</li>
</ul>
<p>The contents of <em>src/lib.rs</em> should have the signatures shown in Listing 12-13
(weve omitted the bodies of the functions for brevity). Note that this wont
compile until we modify <em>src/main.rs</em> in Listing 12-14.</p>
<p><span class="filename">Filename: src/lib.rs</span></p>
<pre><code class="language-rust ignore">use std::error::Error;
use std::fs;
pub struct Config {
pub query: String,
pub filename: String,
}
impl Config {
pub fn new(args: &amp;[String]) -&gt; Result&lt;Config, &amp;'static str&gt; {
// --snip--
}
}
pub fn run(config: Config) -&gt; Result&lt;(), Box&lt;dyn Error&gt;&gt; {
// --snip--
}
</code></pre>
<p><span class="caption">Listing 12-13: Moving <code>Config</code> and <code>run</code> into
<em>src/lib.rs</em></span></p>
<p>Weve made liberal use of the <code>pub</code> keyword: on <code>Config</code>, on its fields and its
<code>new</code> method, and on the <code>run</code> function. We now have a library crate that has a
public API that we can test!</p>
<p>Now we need to bring the code we moved to <em>src/lib.rs</em> into the scope of the
binary crate in <em>src/main.rs</em>, as shown in Listing 12-14.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">use std::env;
use std::process;
use minigrep::Config;
fn main() {
// --snip--
if let Err(e) = minigrep::run(config) {
// --snip--
}
}
</code></pre>
<p><span class="caption">Listing 12-14: Using the <code>minigrep</code> library crate in
<em>src/main.rs</em></span></p>
<p>We add a <code>use minigrep::Config</code> line to bring the <code>Config</code> type from the
library crate into the binary crates scope, and we prefix the <code>run</code> function
with our crate name. Now all the functionality should be connected and should
work. Run the program with <code>cargo run</code> and make sure everything works
correctly.</p>
<p>Whew! That was a lot of work, but weve set ourselves up for success in the
future. Now its much easier to handle errors, and weve made the code more
modular. Almost all of our work will be done in <em>src/lib.rs</em> from here on out.</p>
<p>Lets take advantage of this newfound modularity by doing something that would
have been difficult with the old code but is easy with the new code: well
write some tests!</p>
</main>
<nav class="nav-wrapper" aria-label="Page navigation">
<!-- Mobile navigation buttons -->
<a rel="prev" href="ch12-02-reading-a-file.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next" href="ch12-04-testing-the-librarys-functionality.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
<div style="clear: both"></div>
</nav>
</div>
</div>
<nav class="nav-wide-wrapper" aria-label="Page navigation">
<a href="ch12-02-reading-a-file.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a href="ch12-04-testing-the-librarys-functionality.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
</nav>
</div>
<script type="text/javascript">
window.playpen_copyable = true;
</script>
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
<script src="book.js" type="text/javascript" charset="utf-8"></script>
<!-- Custom JS scripts -->
<script type="text/javascript" src="ferris.js"></script>
</body>
</html>