<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Improving Error Handling and Modularity - 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">
<base href="">
<link rel="stylesheet" href="book.css">
<link href='https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800' rel='stylesheet' type='text/css'>
<link rel="shortcut icon" href="favicon.png">
<!-- Font Awesome -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">
<link rel="stylesheet" href="highlight.css">
<link rel="stylesheet" href="tomorrow-night.css">
<style>
.page-wrapper.has-warning > .nav-chapters {
/* add height for warning content & margin */
top: 120px;
}
p.warning {
background-color: rgb(242, 222, 222);
border-bottom-color: rgb(238, 211, 215);
border-bottom-left-radius: 4px;
border-bottom-right-radius: 4px;
border-bottom-style: solid;
border-bottom-width: 0.666667px;
border-image-outset: 0 0 0 0;
border-image-repeat: stretch stretch;
border-image-slice: 100% 100% 100% 100%;
border-image-source: none;
border-image-width: 1 1 1 1;
border-left-color: rgb(238, 211, 215);
border-left-style: solid;
border-left-width: 0.666667px;
border-right-color: rgb(238, 211, 215);
border-right-style: solid;
border-right-width: 0.666667px;
border-top-color: rgb(238, 211, 215);
border-top-left-radius: 4px;
border-top-right-radius: 4px;
border-top-style: solid;
border-top-width: 0.666667px;
color: rgb(185, 74, 72);
margin-bottom: 0px;
margin-left: 0px;
margin-right: 0px;
margin-top: 30px;
padding-bottom: 8px;
padding-left: 14px;
padding-right: 35px;
padding-top: 8px;
}
p.warning strong {
color: rgb(185, 74, 72)
}
p.warning a {
color: rgb(0, 136, 204)
}
</style>
<!-- MathJax -->
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<!-- Fetch JQuery from CDN but have a local fallback -->
<script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
<script>
if (typeof jQuery == 'undefined') {
document.write(unescape("%3Cscript src='jquery.js'%3E%3C/script%3E"));
}
</script>
</head>
<body class="light">
<!-- Set the theme before any content is loaded, prevents flash -->
<script type="text/javascript">
var theme = localStorage.getItem('theme');
if (theme == null) { theme = 'light'; }
$('body').removeClass().addClass(theme);
</script>
<!-- Hide / unhide sidebar before it is displayed -->
<script type="text/javascript">
var sidebar = localStorage.getItem('sidebar');
if (sidebar === "hidden") { $("html").addClass("sidebar-hidden") }
else if (sidebar === "visible") { $("html").addClass("sidebar-visible") }
</script>
<div id="sidebar" class="sidebar">
<ul class="chapter"><li><a href="ch01-00-introduction.html"><strong>1.</strong> Introduction</a></li><li><ul class="section"><li><a href="ch01-01-installation.html"><strong>1.1.</strong> Installation</a></li><li><a href="ch01-02-hello-world.html"><strong>1.2.</strong> Hello, World!</a></li></ul></li><li><a href="ch02-00-guessing-game-tutorial.html"><strong>2.</strong> Guessing Game Tutorial</a></li><li><a href="ch03-00-common-programming-concepts.html"><strong>3.</strong> Common Programming Concepts</a></li><li><ul class="section"><li><a href="ch03-01-variables-and-mutability.html"><strong>3.1.</strong> Variables and Mutability</a></li><li><a href="ch03-02-data-types.html"><strong>3.2.</strong> Data Types</a></li><li><a href="ch03-03-how-functions-work.html"><strong>3.3.</strong> How Functions Work</a></li><li><a href="ch03-04-comments.html"><strong>3.4.</strong> Comments</a></li><li><a href="ch03-05-control-flow.html"><strong>3.5.</strong> Control Flow</a></li></ul></li><li><a href="ch04-00-understanding-ownership.html"><strong>4.</strong> Understanding Ownership</a></li><li><ul class="section"><li><a href="ch04-01-what-is-ownership.html"><strong>4.1.</strong> What is Ownership?</a></li><li><a href="ch04-02-references-and-borrowing.html"><strong>4.2.</strong> References & Borrowing</a></li><li><a href="ch04-03-slices.html"><strong>4.3.</strong> Slices</a></li></ul></li><li><a href="ch05-00-structs.html"><strong>5.</strong> Using Structs to Structure Related Data</a></li><li><ul class="section"><li><a href="ch05-01-defining-structs.html"><strong>5.1.</strong> Defining and Instantiating Structs</a></li><li><a href="ch05-02-example-structs.html"><strong>5.2.</strong> An Example Program Using Structs</a></li><li><a href="ch05-03-method-syntax.html"><strong>5.3.</strong> Method Syntax</a></li></ul></li><li><a href="ch06-00-enums.html"><strong>6.</strong> Enums and Pattern Matching</a></li><li><ul class="section"><li><a href="ch06-01-defining-an-enum.html"><strong>6.1.</strong> Defining an Enum</a></li><li><a href="ch06-02-match.html"><strong>6.2.</strong> The <code>match</code> Control Flow Operator</a></li><li><a href="ch06-03-if-let.html"><strong>6.3.</strong> Concise Control Flow with <code>if let</code></a></li></ul></li><li><a href="ch07-00-modules.html"><strong>7.</strong> Modules</a></li><li><ul class="section"><li><a href="ch07-01-mod-and-the-filesystem.html"><strong>7.1.</strong> <code>mod</code> and the Filesystem</a></li><li><a href="ch07-02-controlling-visibility-with-pub.html"><strong>7.2.</strong> Controlling Visibility with <code>pub</code></a></li><li><a href="ch07-03-importing-names-with-use.html"><strong>7.3.</strong> Importing Names with <code>use</code></a></li></ul></li><li><a href="ch08-00-common-collections.html"><strong>8.</strong> Common Collections</a></li><li><ul class="section"><li><a href="ch08-01-vectors.html"><strong>8.1.</strong> Vectors</a></li><li><a href="ch08-02-strings.html"><strong>8.2.</strong> Strings</a></li><li><a href="ch08-03-hash-maps.html"><strong>8.3.</strong> Hash Maps</a></li></ul></li><li><a href="ch09-00-error-handling.html"><strong>9.</strong> Error Handling</a></li><li><ul class="section"><li><a href="ch09-01-unrecoverable-errors-with-panic.html"><strong>9.1.</strong> Unrecoverable Errors with <code>panic!</code></a></li><li><a href="ch09-02-recoverable-errors-with-result.html"><strong>9.2.</strong> Recoverable Errors with <code>Result</code></a></li><li><a href="ch09-03-to-panic-or-not-to-panic.html"><strong>9.3.</strong> To <code>panic!</code> or Not To <code>panic!</code></a></li></ul></li><li><a href="ch10-00-generics.html"><strong>10.</strong> Generic Types, Traits, and Lifetimes</a></li><li><ul class="section"><li><a href="ch10-01-syntax.html"><strong>10.1.</strong> Generic Data Types</a></li><li><a href="ch10-02-traits.html"><strong>10.2.</strong> Traits: Defining Shared Behavior</a></li><li><a href="ch10-03-lifetime-syntax.html"><strong>10.3.</strong> Validating References with Lifetimes</a></li></ul></li><li><a href="ch11-00-testing.html"><strong>11.</strong> Testing</a></li><li><ul class="section"><li><a href="ch11-01-writing-tests.html"><strong>11.1.</strong> Writing tests</a></li><li><a href="ch11-02-running-tests.html"><strong>11.2.</strong> Running tests</a></li><li><a href="ch11-03-test-organization.html"><strong>11.3.</strong> Test Organization</a></li></ul></li><li><a href="ch12-00-an-io-project.html"><strong>12.</strong> An I/O Project</a></li><li><ul class="section"><li><a href="ch12-01-accepting-command-line-arguments.html"><strong>12.1.</strong> Accepting Command Line Arguments</a></li><li><a href="ch12-02-reading-a-file.html"><strong>12.2.</strong> Reading a File</a></li><li><a href="ch12-03-improving-error-handling-and-modularity.html" class="active"><strong>12.3.</strong> Improving Error Handling and Modularity</a></li><li><a href="ch12-04-testing-the-librarys-functionality.html"><strong>12.4.</strong> Testing the Library's Functionality</a></li><li><a href="ch12-05-working-with-environment-variables.html"><strong>12.5.</strong> Working with Environment Variables</a></li><li><a href="ch12-06-writing-to-stderr-instead-of-stdout.html"><strong>12.6.</strong> Writing to <code>stderr</code> instead of <code>stdout</code></a></li></ul></li><li><a href="ch13-00-functional-features.html"><strong>13.</strong> Functional Language Features in Rust</a></li><li><ul class="section"><li><a href="ch13-01-closures.html"><strong>13.1.</strong> Closures</a></li><li><a href="ch13-02-iterators.html"><strong>13.2.</strong> Iterators</a></li><li><a href="ch13-03-improving-our-io-project.html"><strong>13.3.</strong> Improving our I/O Project</a></li><li><a href="ch13-04-performance.html"><strong>13.4.</strong> Performance</a></li></ul></li><li><a href="ch14-00-more-about-cargo.html"><strong>14.</strong> More about Cargo and Crates.io</a></li><li><ul class="section"><li><a href="ch14-01-release-profiles.html"><strong>14.1.</strong> Release Profiles</a></li><li><a href="ch14-02-publishing-to-crates-io.html"><strong>14.2.</strong> Publishing a Crate to Crates.io</a></li><li><a href="ch14-03-cargo-workspaces.html"><strong>14.3.</strong> Cargo Workspaces</a></li><li><a href="ch14-04-installing-binaries.html"><strong>14.4.</strong> Installing Binaries from Crates.io with <code>cargo install</code></a></li><li><a href="ch14-05-extending-cargo.html"><strong>14.5.</strong> Extending Cargo with Custom Commands</a></li></ul></li><li><a href="ch15-00-smart-pointers.html"><strong>15.</strong> Smart Pointers</a></li><li><ul class="section"><li><a href="ch15-01-box.html"><strong>15.1.</strong> <code>Box<T></code> Points to Data on the Heap and Has a Known Size</a></li><li><a href="ch15-02-deref.html"><strong>15.2.</strong> The <code>Deref</code> Trait Allows Access to the Data Through a Reference</a></li><li><a href="ch15-03-drop.html"><strong>15.3.</strong> The <code>Drop</code> Trait Runs Code on Cleanup</a></li><li><a href="ch15-04-rc.html"><strong>15.4.</strong> <code>Rc<T></code>, the Reference Counted Smart Pointer</a></li><li><a href="ch15-05-interior-mutability.html"><strong>15.5.</strong> <code>RefCell<T></code> and the Interior Mutability Pattern</a></li><li><a href="ch15-06-reference-cycles.html"><strong>15.6.</strong> Creating Reference Cycles and Leaking Memory is Safe</a></li></ul></li><li><a href="ch16-00-concurrency.html"><strong>16.</strong> Fearless Concurrency</a></li><li><ul class="section"><li><a href="ch16-01-threads.html"><strong>16.1.</strong> Threads</a></li><li><a href="ch16-02-message-passing.html"><strong>16.2.</strong> Message Passing</a></li><li><a href="ch16-03-shared-state.html"><strong>16.3.</strong> Shared State</a></li><li><a href="ch16-04-extensible-concurrency-sync-and-send.html"><strong>16.4.</strong> Extensible Concurrency: <code>Sync</code> and <code>Send</code></a></li></ul></li><li><a href="ch17-00-oop.html"><strong>17.</strong> Is Rust an Object-Oriented Programming Language?</a></li><li><ul class="section"><li><a href="ch17-01-what-is-oo.html"><strong>17.1.</strong> What Does Object-Oriented Mean?</a></li><li><a href="ch17-02-trait-objects.html"><strong>17.2.</strong> Trait Objects for Using Values of Different Types</a></li><li><a href="ch17-03-oo-design-patterns.html"><strong>17.3.</strong> Object-Oriented Design Pattern Implementations</a></li></ul></li><li><a href="ch18-00-patterns.html"><strong>18.</strong> Patterns Match the Structure of Values</a></li><li><ul class="section"><li><a href="ch18-01-all-the-places-for-patterns.html"><strong>18.1.</strong> All the Places Patterns May be Used</a></li><li><a href="ch18-02-refutability.html"><strong>18.2.</strong> Refutability: Whether a Pattern Might Fail to Match</a></li><li><a href="ch18-03-pattern-syntax.html"><strong>18.3.</strong> All the Pattern Syntax</a></li></ul></li><li><a href="ch19-00-advanced-features.html"><strong>19.</strong> Advanced Features</a></li><li><ul class="section"><li><a href="ch19-01-unsafe-rust.html"><strong>19.1.</strong> Unsafe Rust</a></li><li><a href="ch19-02-advanced-lifetimes.html"><strong>19.2.</strong> Advanced Lifetimes</a></li><li><a href="ch19-03-advanced-traits.html"><strong>19.3.</strong> Advanced Traits</a></li><li><a href="ch19-04-advanced-types.html"><strong>19.4.</strong> Advanced Types</a></li><li><a href="ch19-05-advanced-functions-and-closures.html"><strong>19.5.</strong> Advanced Functions & Closures</a></li></ul></li><li><a href="ch20-00-final-project-a-web-server.html"><strong>20.</strong> Final Project: Building a Multithreaded Web Server</a></li><li><ul class="section"><li><a href="ch20-01-single-threaded.html"><strong>20.1.</strong> A Single Threaded Web Server</a></li><li><a href="ch20-02-slow-requests.html"><strong>20.2.</strong> How Slow Requests Affect Throughput</a></li><li><a href="ch20-03-designing-the-interface.html"><strong>20.3.</strong> Designing the Thread Pool Interface</a></li><li><a href="ch20-04-storing-threads.html"><strong>20.4.</strong> Creating the Thread Pool and Storing Threads</a></li><li><a href="ch20-05-sending-requests-via-channels.html"><strong>20.5.</strong> Sending Requests to Threads Via Channels</a></li><li><a href="ch20-06-graceful-shutdown-and-cleanup.html"><strong>20.6.</strong> Graceful Shutdown and Cleanup</a></li></ul></li><li><a href="appendix-00.html"><strong>21.</strong> Appendix</a></li><li><ul class="section"><li><a href="appendix-01-keywords.html"><strong>21.1.</strong> A - Keywords</a></li><li><a href="appendix-02-operators.html"><strong>21.2.</strong> B - Operators</a></li><li><strong>21.3.</strong> C - Derivable Traits</li><li><strong>21.4.</strong> D - Nightly Rust</li><li><strong>21.5.</strong> E - Macros</li><li><strong>21.6.</strong> F - Translations</li><li><a href="appendix-07-newest-features.html"><strong>21.7.</strong> G - Newest Features</a></li></ul></li></ul>
</div>
<div id="page-wrapper" class="page-wrapper has-warning">
<div class="page">
<header><p class="warning">You are reading a <strong>draft</strong> of the next edition of TRPL. For more, go <a href="../index.html">here</a>.</p></header>
<div id="menu-bar" class="menu-bar">
<div class="left-buttons">
<i id="sidebar-toggle" class="fa fa-bars"></i>
<i id="theme-toggle" class="fa fa-paint-brush"></i>
</div>
<h1 class="menu-title">The Rust Programming Language</h1>
<div class="right-buttons">
<i id="print-button" class="fa fa-print" title="Print this book"></i>
</div>
</div>
<div id="content" class="content">
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#refactoring-to-improve-modularity-and-error-handling" id="refactoring-to-improve-modularity-and-error-handling"><h2>Refactoring to Improve Modularity and Error Handling</h2></a>
<p>There are four problems that we'd like to fix to improve our program, and they
have to do with the way the program is structured and how it's handling
potential errors.</p>
<p>First, our <code>main</code> function now performs two tasks: it parses arguments and
opens up files. For such a small function, this isn't a huge problem. However,
if we keep growing our program inside of <code>main</code>, the number of separate tasks
the <code>main</code> function handles will grow. As a function gains responsibilities, it
gets harder to reason about, harder to test, and harder to change without
breaking one of its parts. It's better to separate out functionality so that
each function is responsible for one task.</p>
<p>This also ties into our second problem: while <code>query</code> and <code>filename</code> are
configuration variables to our program, variables like <code>f</code> and <code>contents</code> are
used to perform our program's logic. The longer <code>main</code> gets, the more variables
we're going to need to bring into scope; the more variables we have in scope,
the harder it is to keep track of the purpose of each. It's better to group the
configuration variables into one structure to make their purpose clear.</p>
<p>The third problem is that we've used <code>expect</code> to print out an error message if
opening the file fails, but the error message only says <code>file not found</code>. There
are a number of ways that opening a file can fail besides a missing file: for
example, the file might exist, but we might not have permission to open it.
Right now, if we're in that situation, we'd print the <code>file not found</code> error
message that would give the user the wrong advice!</p>
<p>Fourth, we use <code>expect</code> repeatedly to deal with different errors, and if the
user runs our programs without specifying enough arguments, they'll get an
"index out of bounds" error from Rust that doesn't clearly explain the problem.
It would be better if all our error handling code was in one place so that
future maintainers only have one place to consult in the code if the error
handling logic needs to change. Having all the error handling code in one place
will also help us to ensure that we're printing messages that will be
meaningful to our end users.</p>
<p>Let's address these problems by refactoring our project.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#separation-of-concerns-for-binary-projects" id="separation-of-concerns-for-binary-projects"><h3>Separation of Concerns for Binary Projects</h3></a>
<p>The organizational problem of having the <code>main</code> function responsible for
multiple tasks is common to many binary projects, so the Rust community has
developed a kind of guideline process for splitting up the separate concerns of
a binary program when <code>main</code> starts getting large. The process has the
following steps:</p>
<ol>
<li>Split your program into both a <em>main.rs</em> and a <em>lib.rs</em> and move your
program's logic into <em>lib.rs</em>.</li>
<li>While 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> into <em>lib.rs</em> as well.</li>
<li>The responsibilities that remain in the <code>main</code> function after this process
should be:
<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>If <code>run</code> returns an error, handling that error</li>
</ul>
</li>
</ol>
<p>This pattern is all about separating concerns: <em>main.rs</em> handles running the
program, and <em>lib.rs</em> handles all of the logic of the task at hand. Because we
can't test the <code>main</code> function directly, this structure lets us test all of our
program's 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. Let's re-work our program by following this process.</p>
<!--Since main is already handling the parsing of arguments, why do we need to
add a new function for it, can you say how that improves things? -->
<!-- Sorry, the steps we had were unclear. We've tried rewording. /Carol -->
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#extracting-the-argument-parser" id="extracting-the-argument-parser"><h3>Extracting the Argument Parser</h3></a>
<p>First, we'll extract the functionality for parsing arguments. Listing 12-5
shows the new start of <code>main</code> that calls a new function <code>parse_config</code>, which
we're still going to 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<String> = env::args().collect();
let (query, filename) = parse_config(&args);
// ...snip...
}
fn parse_config(args: &[String]) -> (&str, &str) {
let query = &args[1];
let filename = &args[2];
(query, filename)
}
</code></pre>
<p><span class="caption">Listing 12-5: Extract a <code>parse_config</code> function from
<code>main</code></span></p>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>We're 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 knows 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 knowing how the command line arguments and variables
correspond.</p>
<p>This may seem like overkill for our small program, but we're refactoring in
small, incremental steps. After making this change, run the program again to
verify that the argument parsing still works. It's good to check your progress
often, as that will help you identify the cause of problems when they occur.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#grouping-configuration-values" id="grouping-configuration-values"><h4>Grouping Configuration Values</h4></a>
<p>We can take another small step to improve this function further. At the moment,
we're returning a tuple, but then we immediately break that tuple up into
individual parts again. This is a sign that perhaps we don't have the right
abstraction yet.</p>
<p>Another indicator that there's 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. We're not currently conveying this
meaning in the structure of the data other than 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. This 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>
<!-- above -- I'm not sure why this is a problem --- because they aren't
currently bound together? And why does it imply that -->
<blockquote>
<p>Note: some people call this anti-pattern of using primitive values when a
complex type would be more appropriate <em>primitive obsession</em>.</p>
</blockquote>
<!-- Ah, I see, so the problems here stem from using simple types to do tasks
inefficiently, when a more complex task could handle it in ways that improve...
behavior? Readability? Can you say as much? -->
<!-- I've tried to clarify above. Note that when Rust programmers talk about
"efficiency", they usually mean "run-time performance", whereas here we're
talking about code design and maintainability and not addressing performance
at all. /Carol -->
<p>Listing 12-6 shows the addition of a struct named <code>Config</code> defined to have
fields named <code>query</code> and <code>filename</code>. We've also changed the <code>parse_config</code>
function to return an instance of the <code>Config</code> struct, and updated <code>main</code> to
use the struct fields rather than having separate variables:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust should_panic"># 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.query);
println!("In file {}", config.filename);
let mut f = File::open(config.filename).expect("file not found");
// ...snip...
}
struct Config {
query: String,
filename: String,
}
fn parse_config(args: &[String]) -> Config {
let query = args[1].clone();
let filename = args[2].clone();
Config { query, filename }
}
</code></pre></pre>
<p>Listing 12-6: Refactoring <code>parse_config</code> to return an instance of a <code>Config</code>
struct</p>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>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've now chosen to 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, though, which means we'd violate Rust's borrowing rules if <code>Config</code> tried
to take ownership of the values in <code>args</code>.</p>
<p>There are a number of different ways we could manage the <code>String</code> data, and 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 does take more time and memory than storing a reference to the
string data. However, cloning the data also makes our code very straightforward
since we don't have to manage the lifetimes of the references, so in this
circumstance giving up a little performance to gain simplicity is a worthwhile
trade-off.</p>
<!-- This box is intended to go right after the paragraph talking about `clone`
/Carol -->
<!-- PROD: START BOX -->
<blockquote>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#the-tradeoffs-of-using-clone" id="the-tradeoffs-of-using-clone"><h4>The Tradeoffs of Using <code>clone</code></h4></a>
<p>There's a tendency among many Rustaceans to avoid using <code>clone</code> to fix
ownership problems because of its runtime cost. In Chapter 13 on iterators,
you'll learn how to use more efficient methods in this kind of situation, but
for now, it's okay to copy a few strings to keep making progress since we'll
only make these copies once, and our filename and query string are both very
small. It's better to have a working program that's a bit inefficient than
try to hyper-optimize code on your first pass. As you get more experienced
with Rust, it'll be easier to go straight to the desirable method, but for
now it's perfectly acceptable to call <code>clone</code>.</p>
</blockquote>
<!-- PROD: END BOX -->
<p>We've updated <code>main</code> so that it places the instance of <code>Config</code> that
<code>parse_config</code> returns into a variable named <code>config</code>, and updated the code
that previously used the separate <code>query</code> and <code>filename</code> variables so that is
now uses the fields on the <code>Config</code> struct instead.</p>
<p>Our code now more clearly conveys our intent that <code>query</code> and <code>filename</code> are
related and 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>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#creating-a-constructor-for-config" id="creating-a-constructor-for-config"><h4>Creating a Constructor for <code>Config</code></h4></a>
<!-- Can you lay out what we intend to do in this section? I wasn't sure even
at the end what we did and why --- why did we create it as parse_config to then
change it to new? -->
<!-- We're making small, incremental changes. In addition to being good
software development practice, we were hoping that by changing one thing at a
time, the process of improving code's design would be easier to follow rather
than just jumping to the best solution. We extracted code into a function, then
it was clearer that we should introduce a struct, then it was clear that the
function we extracted is really a constructor of `Config` and should be written
as such. This refactoring process should be familiar to software developers.
I've tried to add a little recap to the start of this section, I hope that
helps. /Carol -->
<p>So far, we've extracted the logic responsible for parsing the command line
arguments from <code>main</code> into the <code>parse_config</code> function, which 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 being a plain function into a
function named <code>new</code> that is associated with the <code>Config</code> struct. Making this
change will make our code more idiomatic: we can create instances of types in
the standard library like <code>String</code> by calling <code>String::new</code>, and by changing
<code>parse_config</code> to be a <code>new</code> function associated with <code>Config</code>, we'll be able
to create instances of <code>Config</code> by calling <code>Config::new</code>. Listing 12-7 shows
the changes we'll need to make:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust should_panic"># use std::env;
#
fn main() {
let args: Vec<String> = env::args().collect();
let config = Config::new(&args);
// ...snip...
}
# struct Config {
# query: String,
# filename: String,
# }
#
// ...snip...
impl Config {
fn new(args: &[String]) -> 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>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>We've updated <code>main</code> where we were calling <code>parse_config</code> to instead call
<code>Config::new</code>. We've changed the name of <code>parse_config</code> to <code>new</code> and moved it
within an <code>impl</code> block, which makes the <code>new</code> function associated with
<code>Config</code>. Try compiling this again to make sure it works.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#fixing-the-error-handling" id="fixing-the-error-handling"><h3>Fixing the Error Handling</h3></a>
<p>Now we'll work on fixing our error handling. Recall that we mentioned
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 3 items. Try
running the program without any arguments; it will look like this:</p>
<pre><code class="language-text">$ cargo run
Finished dev [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.
</code></pre>
<p><code>index out of bounds: the len is 1 but the index is 1</code> is an error message that
is intended for programmers, and won't really help our end users understand
what happened and what they should do instead. Let's fix that now.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#improving-the-error-message" id="improving-the-error-message"><h4>Improving the Error Message</h4></a>
<p>In Listing 12-8, we're adding a check in the <code>new</code> function to check that the
slice is long enough before accessing index 1 and 2. If the slice isn't long
enough, we panic with 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: &[String]) -> Config {
if args.len() < 3 {
panic!("not enough arguments");
}
// ...snip...
</code></pre>
<p><span class="caption">Listing 12-8: Adding a check for the number of
arguments</span></p>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>This is similar to the <code>Guess::new</code> function we wrote in Listing 9-8, where we
called <code>panic!</code> if the <code>value</code> argument was out of the range of valid values.
Instead of checking for a range of values, we're 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 3 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>, let's try running our program
without any arguments again and see what the error looks like now:</p>
<pre><code class="language-bash">$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/greprs`
thread 'main' panicked at 'not enough arguments', src/main.rs:29
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 a bunch of extra information we don't want to give to our users. So
perhaps using the technique we used in Listing 9-8 isn't the best to use here;
a call to <code>panic!</code> is more appropriate for a programming problem rather than a
usage problem anyway, as we discussed in Chapter 9. Instead, we can use the
other technique we learned about in that chapter: returning a <code>Result</code> that can
indicate either success or an error.</p>
<!-- Below -- how does using new fix this, can you lay that our up front? -->
<!-- I'm not sure what you mean, we're already using `new` and the fix continues
to use `new`... /Carol -->
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#returning-a-result-from-new-instead-of-calling-panic" id="returning-a-result-from-new-instead-of-calling-panic"><h4>Returning a <code>Result</code> from <code>new</code> Instead of Calling <code>panic!</code></h4></a>
<p>We can choose to 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 Rust's way of
signaling that there was a problem using the <code>Result</code> type. Then we can change
<code>main</code> to convert an <code>Err</code> variant into a nicer 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 to the return value of <code>Config::new</code> and the
body of the function needed to return a <code>Result</code>:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">impl Config {
fn new(args: &[String]) -> Result<Config, &'static str> {
if args.len() < 3 {
return Err("not enough arguments");
}
let query = args[1].clone();
let filename = args[2].clone();
Ok(Config { query, filename })
}
}
</code></pre>
<p><span class="caption">Listing 12-9: Return a <code>Result</code> from <code>Config::new</code></span></p>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<!-- what does returning a Result rather than a Config do? -->
<!-- This is what Chapter 9 was about, I've added a few more references
to that chapter to reinforce the connection /Carol -->
<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>&'static str</code> in the error case. Recall from "The Static
Lifetime" section in Chapter 10 that <code>&'static str</code> is the type of string
literals, which is our error message type for now.</p>
<p>We've made two changes in the body of the <code>new</code> function: instead of calling
<code>panic!</code> when the user doesn't pass enough arguments, we now return an <code>Err</code>
value, and we've 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>By having <code>Config::new</code> return an <code>Err</code> value, it 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>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#calling-confignew-and-handling-errors" id="calling-confignew-and-handling-errors"><h4>Calling <code>Config::new</code> and Handling Errors</h4></a>
<p>In order to handle the error case and print a user-friendly message, we need to
update <code>main</code> to handle the <code>Result</code> that <code>Config::new</code> is now returning as
shown in Listing 12-10. We're also going to implement by hand something that
<code>panic!</code> handled for us: exiting the command line tool with an error code of 1.
A nonzero exit status is a convention to signal to the process that called our
program that our program ended 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<String> = env::args().collect();
let config = Config::new(&args).unwrap_or_else(|err| {
println!("Problem parsing arguments: {}", 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>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<!-- In the `main` function itself, we'll handle the `Result` value returned
from the `new` function and exit the process in a cleaner way if `Config::new`
returns an `Err` value.-->
<!-- I moved this line above to the previous section, it seems to at least
partially answer some of my earlier confusions, though I'm not following this
as well as I'd like so not sure if I have this right, can you confirm either
way whether that move makes sense? -->
<!-- That's fine /Carol -->
<p>In this listing, we're using a method we haven't covered before:
<code>unwrap_or_else</code>, which is defined on <code>Result<T, E></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 method's 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>. We'll
be covering closures in more detail in Chapter 13. What you need to know for
now is 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>
<!--Can you give a high-level idea of what the closure does with it? -->
<!-- Does with what? I've tried to elaborate in the above and below paragraphs,
but I'm not sure exactly what's confusing /Carol -->
<p>We've added a new <code>use</code> line to import <code>process</code> from the standard library. The
code in the closure that will get run in the error case is only two lines: we
print out the <code>err</code> value, then call <code>std::process::exit</code> (we've added a new
<code>use</code> line at the top to import <code>process</code> from the standard library).
<code>process::exit</code> 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, with the exception that we no longer get all
the extra output. Let's try it:</p>
<pre><code class="language-text">$ cargo run
Compiling greprs v0.1.0 (file:///projects/greprs)
Finished dev [unoptimized + debuginfo] target(s) in 0.48 secs
Running `target/debug/greprs`
Problem parsing arguments: not enough arguments
</code></pre>
<p>Great! This output is much friendlier for our users.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#extracting-a-run-function" id="extracting-a-run-function"><h3>Extracting a <code>run</code> Function</h3></a>
<p>Now we're done refactoring our configuration parsing; let's turn to our
program's logic. As we laid out in the process we discussed in the "Separation
of Concerns for Binary Projects" section, we're going to extract a function
named <code>run</code> that will hold all of the logic currently in the <code>main</code> function
that isn't setting up configuration or handling errors. Once we're done, <code>main</code>
will be concise and easy to verify by inspection, and we'll be able to write
tests for all of the other logic.</p>
<!-- it contains ALL the function from main? Can you say why we're doing this,
hw this improves it? What is the run function doing? I'm afraid I feel a bit in
the dark here-->
<!-- This is the pattern that we explained in the Separation of Concerns for
Binary Projects section. I've added a reference back to that and reiterated
some of the reasoning from there, but this section isn't introducing the
concept of the `run` function holding the logic that was in `main` /Carol -->
<p>Listing 12-11 shows the extracted <code>run</code> function. For now, we're making only
the small, incremental improvement of extracting the function and 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!("Searching for {}", config.query);
println!("In file {}", config.filename);
run(config);
}
fn run(config: Config) {
let mut f = File::open(config.filename).expect("file not found");
let mut contents = String::new();
f.read_to_string(&mut contents).expect("something went wrong reading the file");
println!("With text:\n{}", 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>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<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>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#returning-errors-from-the-run-function" id="returning-errors-from-the-run-function"><h4>Returning Errors from the <code>run</code> Function</h4></a>
<p>With the remaining program logic separated into the <code>run</code> function rather than
being in <code>main</code>, we can improve the error handling like 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<T, E></code> when
something goes wrong. This will let us further consolidate the logic around
handling errors in a user-friendly way into <code>main</code>. Listing 12-12 shows the
changes 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) -> 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(())
}
</code></pre>
<p><span class="caption">Listing 12-12: Changing the <code>run</code> function to return
<code>Result</code></span></p>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>We've made three big changes here. First, we're changing the return type of the
<code>run</code> function to <code>Result<(), Box<Error>></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>
<!-- is just the `Box` bit the trait object, or the whole `Box<Error>`
syntax?-->
<!-- The whole `Box<Error>` /Carol -->
<p>For our error type, we're using the <em>trait object</em> <code>Box<Error></code> (and we've
brought <code>std::error::Error</code> into scope with a <code>use</code> statement at the top).
We'll be covering trait objects in Chapter 17. For now, just know that
<code>Box<Error></code> means the function will return a type that implements the <code>Error</code>
trait, but we don't 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.</p>
<p>The second change we're making is removing the calls to <code>expect</code> in favor of
<code>?</code>, like we talked about in Chapter 9. Rather than <code>panic!</code> on an error, this
will return the error value from the current function for the caller to handle.</p>
<p>Thirdly, this function now returns an <code>Ok</code> value in the success case. We've
declared the <code>run</code> function's 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 may look a bit strange at first, but using <code>()</code> like this is the
idiomatic way to indicate that we're calling <code>run</code> for its side effects only;
it doesn't return a value we need.</p>
<p>When you run this, it will compile, but with a warning:</p>
<pre><code class="language-text">warning: unused result which must be used, #[warn(unused_must_use)] on by default
--> src/main.rs:39:5
|
39 | run(config);
| ^^^^^^^^^^^^
</code></pre>
<p>Rust is telling us that our code ignores the <code>Result</code> value, which might be
indicating that there was an error. We're not checking to see if there was an
error or not, though, and the compiler is reminding us that we probably meant
to have some error handling code here! Let's rectify that now.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#handling-errors-returned-from-run-in-main" id="handling-errors-returned-from-run-in-main"><h4>Handling Errors Returned from <code>run</code> in <code>main</code></h4></a>
<p>We'll check for errors and handle them nicely using a similar technique to the
way we handled errors 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!("Searching for {}", config.query);
println!("In file {}", config.filename);
if let Err(e) = run(config) {
println!("Application error: {}", e);
process::exit(1);
}
}
</code></pre>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>We use <code>if let</code> to check whether <code>run</code> returns an <code>Err</code> value, rather than
<code>unwrap_or_else</code>, and call <code>process::exit(1)</code> if it does. <code>run</code> doesn't return
a value that we want to <code>unwrap</code> like <code>Config::new</code> returns the <code>Config</code>
instance. Because <code>run</code> returns a <code>()</code> in the success case, we only care about
detecting an error, so we don't need <code>unwrap_or_else</code> to return the unwrapped
value as 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 though: we print out the error and exit.</p>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#split-code-into-a-library-crate" id="split-code-into-a-library-crate"><h3>Split Code into a Library Crate</h3></a>
<p>This is looking pretty good so far! Now we're going to split the <em>src/main.rs</em>
file up and put some code into <em>src/lib.rs</em> so that we can test it and have a
small <code>main</code> function.</p>
<p>Let's move the following pieces of code from <em>src/main.rs</em> to a new file,
<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 now look like Listing 12-13:</p>
<p><span class="filename">Filename: src/lib.rs</span></p>
<pre><code class="language-rust ignore">use std::error::Error;
use std::fs::File;
use std::io::prelude::*;
pub struct Config {
pub query: String,
pub filename: String,
}
impl Config {
pub fn new(args: &[String]) -> Result<Config, &'static str> {
if args.len() < 3 {
return Err("not enough arguments");
}
let query = args[1].clone();
let filename = args[2].clone();
Ok(Config { query, filename })
}
}
pub 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(())
}
</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>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>We've made liberal use of <code>pub</code> here: on <code>Config</code>, 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>
<a class="header" href="ch12-03-improving-error-handling-and-modularity.html#calling-the-library-crate-from-the-binary-crate" id="calling-the-library-crate-from-the-binary-crate"><h4>Calling the Library Crate from the Binary Crate</h4></a>
<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> by using <code>extern crate greprs</code>. Then we'll add a
<code>use greprs::Config</code> line to bring the <code>Config</code> type into scope, and prefix the
<code>run</code> function with our crate name as shown in Listing 12-14:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><code class="language-rust ignore">extern crate greprs;
use std::env;
use std::process;
use greprs::Config;
fn main() {
let args: Vec<String> = env::args().collect();
let config = Config::new(&args).unwrap_or_else(|err| {
println!("Problem parsing arguments: {}", err);
process::exit(1);
});
println!("Searching for {}", config.query);
println!("In file {}", config.filename);
if let Err(e) = greprs::run(config) {
println!("Application error: {}", e);
process::exit(1);
}
}
</code></pre>
<p><span class="caption">Listing 12-14: Bringing the <code>greprs</code> crate into the scope
of <em>src/main.rs</em></span></p>
<!-- Will add ghosting and wingdings in libreoffice /Carol -->
<p>With that, all the functionality should be connected and should work. Give it a
<code>cargo run</code> and make sure everything is wired up correctly.</p>
<!-- any tips for if they do find something is broken, main places to check? Or
just "diff your file against the XXX file in the book's resources to check
where it went wrong"? -->
<!-- We think general troubleshooting tips should be something we cover in
Chapter 1; the tips should apply to any example in the book /Carol -->
<p>Whew! That was a lot of work, but we've set ourselves up for success in the
future. Now it's much easier to handle errors, and we've made our code more
modular. Almost all of our work will be done in <em>src/lib.rs</em> from here on out.</p>
<p>Let's take advantage of this newfound modularity by doing something that would
have been hard with our old code, but is easy with our new code: write some
tests!</p>
</div>
<!-- Mobile navigation buttons -->
<a href="ch12-02-reading-a-file.html" class="mobile-nav-chapters previous">
<i class="fa fa-angle-left"></i>
</a>
<a href="ch12-04-testing-the-librarys-functionality.html" class="mobile-nav-chapters next">
<i class="fa fa-angle-right"></i>
</a>
</div>
<a href="ch12-02-reading-a-file.html" class="nav-chapters previous" title="You can navigate through the chapters using the arrow keys">
<i class="fa fa-angle-left"></i>
</a>
<a href="ch12-04-testing-the-librarys-functionality.html" class="nav-chapters next" title="You can navigate through the chapters using the arrow keys">
<i class="fa fa-angle-right"></i>
</a>
</div>
<!-- Local fallback for Font Awesome -->
<script>
if ($(".fa").css("font-family") !== "FontAwesome") {
$('<link rel="stylesheet" type="text/css" href="_FontAwesome/css/font-awesome.css">').prependTo('head');
}
</script>
<!-- Livereload script (if served using the cli tool) -->
<script src="highlight.js"></script>
<script src="book.js"></script>
</body>
</html>
distrib
>
Mageia
>
6
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
564935689ab5527f955e5449ded02799
>
files
>
270
