1061 lines
69 KiB
HTML
1061 lines
69 KiB
HTML
<!DOCTYPE HTML>
|
||
<html lang="en" class="light sidebar-visible" dir="ltr">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>Refactoring to Improve Modularity and Error Handling - The Rust Programming Language</title>
|
||
|
||
|
||
<!-- Custom HTML head -->
|
||
|
||
<meta name="description" content="">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
<meta name="theme-color" content="#ffffff">
|
||
|
||
<link rel="icon" href="favicon-de23e50b.svg">
|
||
<link rel="shortcut icon" href="favicon-8114d1fc.png">
|
||
<link rel="stylesheet" href="css/variables-8adf115d.css">
|
||
<link rel="stylesheet" href="css/general-0392ca55.css">
|
||
<link rel="stylesheet" href="css/chrome-fc474251.css">
|
||
<link rel="stylesheet" href="css/print-9e4910d8.css" media="print">
|
||
|
||
<!-- Fonts -->
|
||
<link rel="stylesheet" href="fonts/fonts-9644e21d.css">
|
||
|
||
<!-- Highlight.js Stylesheets -->
|
||
<link rel="stylesheet" id="mdbook-highlight-css" href="highlight-493f70e1.css">
|
||
<link rel="stylesheet" id="mdbook-tomorrow-night-css" href="tomorrow-night-4c0ae647.css">
|
||
<link rel="stylesheet" id="mdbook-ayu-highlight-css" href="ayu-highlight-3fdfc3ac.css">
|
||
|
||
<!-- Custom theme stylesheets -->
|
||
<link rel="stylesheet" href="ferris-d33b75bf.css">
|
||
<link rel="stylesheet" href="theme/2018-edition-4e126c62.css">
|
||
<link rel="stylesheet" href="theme/semantic-notes-9b5766c0.css">
|
||
<link rel="stylesheet" href="theme/listing-cab26221.css">
|
||
|
||
|
||
<!-- Provide site root and default themes to javascript -->
|
||
<script>
|
||
const path_to_root = "";
|
||
const default_light_theme = "light";
|
||
const default_dark_theme = "navy";
|
||
window.path_to_searchindex_js = "searchindex-6a1da8cc.js";
|
||
</script>
|
||
<!-- Start loading toc.js asap -->
|
||
<script src="toc-0e4ce700.js"></script>
|
||
</head>
|
||
<body>
|
||
<div id="mdbook-help-container">
|
||
<div id="mdbook-help-popup">
|
||
<h2 class="mdbook-help-title">Keyboard shortcuts</h2>
|
||
<div>
|
||
<p>Press <kbd>←</kbd> or <kbd>→</kbd> to navigate between chapters</p>
|
||
<p>Press <kbd>S</kbd> or <kbd>/</kbd> to search in the book</p>
|
||
<p>Press <kbd>?</kbd> to show this help</p>
|
||
<p>Press <kbd>Esc</kbd> to hide this help</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div id="mdbook-body-container">
|
||
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
||
<script>
|
||
try {
|
||
let theme = localStorage.getItem('mdbook-theme');
|
||
let 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>
|
||
const default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? default_dark_theme : default_light_theme;
|
||
let theme;
|
||
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
||
if (theme === null || theme === undefined) { theme = default_theme; }
|
||
const html = document.documentElement;
|
||
html.classList.remove('light')
|
||
html.classList.add(theme);
|
||
html.classList.add("js");
|
||
</script>
|
||
|
||
<input type="checkbox" id="mdbook-sidebar-toggle-anchor" class="hidden">
|
||
|
||
<!-- Hide / unhide sidebar before it is displayed -->
|
||
<script>
|
||
let sidebar = null;
|
||
const sidebar_toggle = document.getElementById("mdbook-sidebar-toggle-anchor");
|
||
if (document.body.clientWidth >= 1080) {
|
||
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
||
sidebar = sidebar || 'visible';
|
||
} else {
|
||
sidebar = 'hidden';
|
||
sidebar_toggle.checked = false;
|
||
}
|
||
if (sidebar === 'visible') {
|
||
sidebar_toggle.checked = true;
|
||
} else {
|
||
html.classList.remove('sidebar-visible');
|
||
}
|
||
</script>
|
||
|
||
<nav id="mdbook-sidebar" class="sidebar" aria-label="Table of contents">
|
||
<!-- populated by js -->
|
||
<mdbook-sidebar-scrollbox class="sidebar-scrollbox"></mdbook-sidebar-scrollbox>
|
||
<noscript>
|
||
<iframe class="sidebar-iframe-outer" src="toc.html"></iframe>
|
||
</noscript>
|
||
<div id="mdbook-sidebar-resize-handle" class="sidebar-resize-handle">
|
||
<div class="sidebar-resize-indicator"></div>
|
||
</div>
|
||
</nav>
|
||
|
||
<div id="mdbook-page-wrapper" class="page-wrapper">
|
||
|
||
<div class="page">
|
||
<div id="mdbook-menu-bar-hover-placeholder"></div>
|
||
<div id="mdbook-menu-bar" class="menu-bar sticky">
|
||
<div class="left-buttons">
|
||
<label id="mdbook-sidebar-toggle" class="icon-button" for="mdbook-sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="mdbook-sidebar">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M0 96C0 78.3 14.3 64 32 64H416c17.7 0 32 14.3 32 32s-14.3 32-32 32H32C14.3 128 0 113.7 0 96zM0 256c0-17.7 14.3-32 32-32H416c17.7 0 32 14.3 32 32s-14.3 32-32 32H32c-17.7 0-32-14.3-32-32zM448 416c0 17.7-14.3 32-32 32H32c-17.7 0-32-14.3-32-32s14.3-32 32-32H416c17.7 0 32 14.3 32 32z"/></svg></span>
|
||
</label>
|
||
<button id="mdbook-theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="mdbook-theme-list">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 576 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M371.3 367.1c27.3-3.9 51.9-19.4 67.2-42.9L600.2 74.1c12.6-19.5 9.4-45.3-7.6-61.2S549.7-4.4 531.1 9.6L294.4 187.2c-24 18-38.2 46.1-38.4 76.1L371.3 367.1zm-19.6 25.4l-116-104.4C175.9 290.3 128 339.6 128 400c0 3.9 .2 7.8 .6 11.6c1.8 17.5-10.2 36.4-27.8 36.4H96c-17.7 0-32 14.3-32 32s14.3 32 32 32H240c61.9 0 112-50.1 112-112c0-2.5-.1-5-.2-7.5z"/></svg></span>
|
||
</button>
|
||
<ul id="mdbook-theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
||
<li role="none"><button role="menuitem" class="theme" id="mdbook-theme-default_theme">Auto</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="mdbook-theme-light">Light</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="mdbook-theme-rust">Rust</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="mdbook-theme-coal">Coal</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="mdbook-theme-navy">Navy</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="mdbook-theme-ayu">Ayu</button></li>
|
||
</ul>
|
||
<button id="mdbook-search-toggle" class="icon-button" type="button" title="Search (`/`)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="/ s" aria-controls="mdbook-searchbar">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M416 208c0 45.9-14.9 88.3-40 122.7L502.6 457.4c12.5 12.5 12.5 32.8 0 45.3s-32.8 12.5-45.3 0L330.7 376c-34.4 25.2-76.8 40-122.7 40C93.1 416 0 322.9 0 208S93.1 0 208 0S416 93.1 416 208zM208 352c79.5 0 144-64.5 144-144s-64.5-144-144-144S64 128.5 64 208s64.5 144 144 144z"/></svg></span>
|
||
</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">
|
||
<span class=fa-svg id="print-button"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M128 0C92.7 0 64 28.7 64 64v96h64V64H354.7L384 93.3V160h64V93.3c0-17-6.7-33.3-18.7-45.3L400 18.7C388 6.7 371.7 0 354.7 0H128zM384 352v32 64H128V384 368 352H384zm64 32h32c17.7 0 32-14.3 32-32V256c0-35.3-28.7-64-64-64H64c-35.3 0-64 28.7-64 64v96c0 17.7 14.3 32 32 32H64v64c0 35.3 28.7 64 64 64H384c35.3 0 64-28.7 64-64V384zm-16-88c-13.3 0-24-10.7-24-24s10.7-24 24-24s24 10.7 24 24s-10.7 24-24 24z"/></svg></span>
|
||
</a>
|
||
<a href="https://github.com/rust-lang/book" title="Git repository" aria-label="Git repository">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6zm-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3zm44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9zM244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8zM97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1zm-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7zm32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1zm-11.4-14.7c-1.6 1-1.6 3.6 0 5.9 1.6 2.3 4.3 3.3 5.6 2.3 1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2z"/></svg></span>
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div id="mdbook-search-wrapper" class="hidden">
|
||
<form id="mdbook-searchbar-outer" class="searchbar-outer">
|
||
<div class="search-wrapper">
|
||
<input type="search" id="mdbook-searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="mdbook-searchresults-outer" aria-describedby="searchresults-header">
|
||
<div class="spinner-wrapper">
|
||
<span class=fa-svg id="fa-spin"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M304 48c0-26.5-21.5-48-48-48s-48 21.5-48 48s21.5 48 48 48s48-21.5 48-48zm0 416c0-26.5-21.5-48-48-48s-48 21.5-48 48s21.5 48 48 48s48-21.5 48-48zM48 304c26.5 0 48-21.5 48-48s-21.5-48-48-48s-48 21.5-48 48s21.5 48 48 48zm464-48c0-26.5-21.5-48-48-48s-48 21.5-48 48s21.5 48 48 48s48-21.5 48-48zM142.9 437c18.7-18.7 18.7-49.1 0-67.9s-49.1-18.7-67.9 0s-18.7 49.1 0 67.9s49.1 18.7 67.9 0zm0-294.2c18.7-18.7 18.7-49.1 0-67.9S93.7 56.2 75 75s-18.7 49.1 0 67.9s49.1 18.7 67.9 0zM369.1 437c18.7 18.7 49.1 18.7 67.9 0s18.7-49.1 0-67.9s-49.1-18.7-67.9 0s-18.7 49.1 0 67.9z"/></svg></span>
|
||
</div>
|
||
</div>
|
||
</form>
|
||
<div id="mdbook-searchresults-outer" class="searchresults-outer hidden">
|
||
<div id="mdbook-searchresults-header" class="searchresults-header"></div>
|
||
<ul id="mdbook-searchresults">
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
||
<script>
|
||
document.getElementById('mdbook-sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
||
document.getElementById('mdbook-sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
||
Array.from(document.querySelectorAll('#mdbook-sidebar a')).forEach(function(link) {
|
||
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
||
});
|
||
</script>
|
||
|
||
<div id="mdbook-content" class="content">
|
||
<main>
|
||
<h2 id="refactoring-to-improve-modularity-and-error-handling"><a class="header" href="#refactoring-to-improve-modularity-and-error-handling">Refactoring to Improve Modularity and Error Handling</a></h2>
|
||
<p>To improve our program, we’ll fix four problems that have to do with the
|
||
program’s structure and how it’s handling potential errors. First, our <code>main</code>
|
||
function now performs two tasks: It parses arguments and reads files. As our
|
||
program grows, 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. It’s best to separate functionality so that each function is responsible
|
||
for one task.</p>
|
||
<p>This issue also ties into the second problem: Although <code>query</code> and <code>file_path</code>
|
||
are configuration variables to our program, variables like <code>contents</code> are used
|
||
to perform the program’s logic. The longer <code>main</code> becomes, the more variables
|
||
we’ll 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. It’s best 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 an error message when
|
||
reading the file fails, but the error message just prints <code>Should have been able to read 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, we’d print the same error message for
|
||
everything, which wouldn’t give the user any information!</p>
|
||
<p>Fourth, we use <code>expect</code> to handle an error, and if the user runs our program
|
||
without specifying enough arguments, they’ll get an <code>index out of bounds</code> error
|
||
from Rust that doesn’t clearly explain the problem. It would be best if all the
|
||
error-handling code were in one place so that future maintainers had only one
|
||
place to consult the code if the error-handling logic needed to change. Having
|
||
all the error-handling code in one place will also ensure that we’re printing
|
||
messages that will be meaningful to our end users.</p>
|
||
<p>Let’s address these four problems by refactoring our project.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="separation-of-concerns-for-binary-projects"></a></p>
|
||
<h3 id="separating-concerns-in-binary-projects"><a class="header" href="#separating-concerns-in-binary-projects">Separating Concerns in 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, many Rust
|
||
programmers find it useful to split up the separate concerns of a binary
|
||
program when the <code>main</code> function starts getting large. This process has the
|
||
following steps:</p>
|
||
<ul>
|
||
<li>Split your program into a <em>main.rs</em> file and a <em>lib.rs</em> file and move your
|
||
program’s logic to <em>lib.rs</em>.</li>
|
||
<li>As long as your command line parsing logic is small, it can remain in
|
||
the <code>main</code> function.</li>
|
||
<li>When the command line parsing logic starts getting complicated, extract it
|
||
from the <code>main</code> function into other functions or types.</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
|
||
can’t test the <code>main</code> function directly, this structure lets you test all of
|
||
your program’s logic by moving it out of the <code>main</code> function. The code that
|
||
remains in the <code>main</code> function will be small enough to verify its correctness
|
||
by reading it. Let’s rework our program by following this process.</p>
|
||
<h4 id="extracting-the-argument-parser"><a class="header" href="#extracting-the-argument-parser">Extracting the Argument Parser</a></h4>
|
||
<p>We’ll extract the functionality for parsing arguments into a function that
|
||
<code>main</code> will call. Listing 12-5 shows the new start of the <code>main</code> function that
|
||
calls a new function <code>parse_config</code>, which we’ll define in <em>src/main.rs</em>.</p>
|
||
<figure class="listing" id="listing-12-5">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">
|
||
</span>fn main() {
|
||
let args: Vec<String> = env::args().collect();
|
||
|
||
let (query, file_path) = parse_config(&args);
|
||
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring"> println!("Searching for {query}");
|
||
</span><span class="boring"> println!("In file {file_path}");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let contents = fs::read_to_string(file_path)
|
||
</span><span class="boring"> .expect("Should have been able to read the file");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span>}
|
||
|
||
fn parse_config(args: &[String]) -> (&str, &str) {
|
||
let query = &args[1];
|
||
let file_path = &args[2];
|
||
|
||
(query, file_path)
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-12-5">Listing 12-5</a>: Extracting a <code>parse_config</code> function from <code>main</code></figcaption>
|
||
</figure>
|
||
<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>file_path</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>file_path</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 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, to help identify the cause of problems when they occur.</p>
|
||
<h4 id="grouping-configuration-values"><a class="header" href="#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, we’re returning a tuple, but then we immediately break that
|
||
tuple into individual parts again. This is a sign that perhaps we don’t have
|
||
the right abstraction yet.</p>
|
||
<p>Another indicator that shows 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 by grouping the two values into
|
||
a tuple; we’ll instead 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>
|
||
<p>Listing 12-6 shows the improvements to the <code>parse_config</code> function.</p>
|
||
<figure class="listing" id="listing-12-6">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust should_panic noplayground"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">
|
||
</span>fn main() {
|
||
let args: Vec<String> = env::args().collect();
|
||
|
||
let config = parse_config(&args);
|
||
|
||
println!("Searching for {}", config.query);
|
||
println!("In file {}", config.file_path);
|
||
|
||
let contents = fs::read_to_string(config.file_path)
|
||
.expect("Should have been able to read the file");
|
||
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span>}
|
||
|
||
struct Config {
|
||
query: String,
|
||
file_path: String,
|
||
}
|
||
|
||
fn parse_config(args: &[String]) -> Config {
|
||
let query = args[1].clone();
|
||
let file_path = args[2].clone();
|
||
|
||
Config { query, file_path }
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-12-6">Listing 12-6</a>: Refactoring <code>parse_config</code> to return an instance of a <code>Config</code> struct</figcaption>
|
||
</figure>
|
||
<p>We’ve added a struct named <code>Config</code> defined to have fields named <code>query</code> and
|
||
<code>file_path</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 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 ways we could manage the <code>String</code> data; 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
|
||
don’t 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>
|
||
<section class="note" aria-role="note">
|
||
<h3 id="the-trade-offs-of-using-clone"><a class="header" href="#the-trade-offs-of-using-clone">The Trade-Offs of Using <code>clone</code></a></h3>
|
||
<p>There’s 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 -->, you’ll learn how to use more efficient
|
||
methods in this type of situation. But for now, it’s okay to copy a few
|
||
strings to continue making progress because you’ll make these copies only
|
||
once and your file path and query string are very small. It’s better to have
|
||
a working program that’s a bit inefficient than to try to hyperoptimize code
|
||
on your first pass. As you become more experienced with Rust, it’ll be
|
||
easier to start with the most efficient solution, but for now, it’s
|
||
perfectly acceptable to call <code>clone</code>.</p>
|
||
</section>
|
||
<p>We’ve updated <code>main</code> so that 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>file_path</code> variables so that 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>file_path</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 id="creating-a-constructor-for-config"><a class="header" href="#creating-a-constructor-for-config">Creating a Constructor for <code>Config</code></a></h4>
|
||
<p>So far, we’ve 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 see that the <code>query</code> and <code>file_path</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>file_path</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>, we’ll
|
||
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>
|
||
<figure class="listing" id="listing-12-7">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust should_panic noplayground"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">
|
||
</span>fn main() {
|
||
let args: Vec<String> = env::args().collect();
|
||
|
||
let config = Config::new(&args);
|
||
<span class="boring">
|
||
</span><span class="boring"> println!("Searching for {}", config.query);
|
||
</span><span class="boring"> println!("In file {}", config.file_path);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let contents = fs::read_to_string(config.file_path)
|
||
</span><span class="boring"> .expect("Should have been able to read the file");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span>
|
||
// --snip--
|
||
}
|
||
|
||
// --snip--
|
||
|
||
<span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Config {
|
||
fn new(args: &[String]) -> Config {
|
||
let query = args[1].clone();
|
||
let file_path = args[2].clone();
|
||
|
||
Config { query, file_path }
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-12-7">Listing 12-7</a>: Changing <code>parse_config</code> into <code>Config::new</code></figcaption>
|
||
</figure>
|
||
<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 associates the <code>new</code> function with <code>Config</code>. Try
|
||
compiling this code again to make sure it works.</p>
|
||
<h3 id="fixing-the-error-handling"><a class="header" href="#fixing-the-error-handling">Fixing the Error Handling</a></h3>
|
||
<p>Now we’ll 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-console">$ cargo run
|
||
Compiling minigrep v0.1.0 (file:///projects/minigrep)
|
||
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s
|
||
Running `target/debug/minigrep`
|
||
|
||
thread 'main' panicked at src/main.rs:27:21:
|
||
index out of bounds: the len is 1 but the index is 1
|
||
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
|
||
</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 won’t help our end users understand what
|
||
they should do instead. Let’s fix that now.</p>
|
||
<h4 id="improving-the-error-message"><a class="header" href="#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 index 2. If the slice isn’t
|
||
long enough, the program panics and displays a better error message.</p>
|
||
<figure class="listing" id="listing-12-8">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">
|
||
</span><span class="boring">fn main() {
|
||
</span><span class="boring"> let args: Vec<String> = env::args().collect();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let config = Config::new(&args);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("Searching for {}", config.query);
|
||
</span><span class="boring"> println!("In file {}", config.file_path);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let contents = fs::read_to_string(config.file_path)
|
||
</span><span class="boring"> .expect("Should have been able to read the file");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Config {
|
||
</span> // --snip--
|
||
fn new(args: &[String]) -> Config {
|
||
if args.len() < 3 {
|
||
panic!("not enough arguments");
|
||
}
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring"> let query = args[1].clone();
|
||
</span><span class="boring"> let file_path = args[2].clone();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Config { query, file_path }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></code></pre>
|
||
<figcaption><a href="#listing-12-8">Listing 12-8</a>: Adding a check for the number of arguments</figcaption>
|
||
</figure>
|
||
<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-13</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, we’re checking that the length of <code>args</code> is at least
|
||
<code>3</code> 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 <code>true</code>, 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 run the program without any
|
||
arguments again to see what the error looks like now:</p>
|
||
<pre><code class="language-console">$ cargo run
|
||
Compiling minigrep v0.1.0 (file:///projects/minigrep)
|
||
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s
|
||
Running `target/debug/minigrep`
|
||
|
||
thread 'main' panicked at src/main.rs:26:13:
|
||
not enough arguments
|
||
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
|
||
</code></pre>
|
||
<p>This output is better: We now have a reasonable error message. However, we also
|
||
have extraneous information we don’t want to give to our users. Perhaps the
|
||
technique we used in Listing 9-13 isn’t the best one 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’ll 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>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="returning-a-result-from-new-instead-of-calling-panic"></a></p>
|
||
<h4 id="returning-a-result-instead-of-calling-panic"><a class="header" href="#returning-a-result-instead-of-calling-panic">Returning a <code>Result</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. We’re also
|
||
going to change the function name from <code>new</code> to <code>build</code> because many
|
||
programmers expect <code>new</code> functions to never fail. When <code>Config::build</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 the
|
||
function we’re now calling <code>Config::build</code> and the body of the function needed
|
||
to return a <code>Result</code>. Note that this won’t compile until we update <code>main</code> as
|
||
well, which we’ll do in the next listing.</p>
|
||
<figure class="listing" id="listing-12-9">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">
|
||
</span><span class="boring">fn main() {
|
||
</span><span class="boring"> let args: Vec<String> = env::args().collect();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let config = Config::new(&args);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("Searching for {}", config.query);
|
||
</span><span class="boring"> println!("In file {}", config.file_path);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let contents = fs::read_to_string(config.file_path)
|
||
</span><span class="boring"> .expect("Should have been able to read the file");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Config {
|
||
fn build(args: &[String]) -> Result<Config, &'static str> {
|
||
if args.len() < 3 {
|
||
return Err("not enough arguments");
|
||
}
|
||
|
||
let query = args[1].clone();
|
||
let file_path = args[2].clone();
|
||
|
||
Ok(Config { query, file_path })
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-12-9">Listing 12-9</a>: Returning a <code>Result</code> from <code>Config::build</code></figcaption>
|
||
</figure>
|
||
<p>Our <code>build</code> function returns a <code>Result</code> with a <code>Config</code> instance in the success
|
||
case and a string literal in the error case. Our error values will always be
|
||
string literals that have the <code>'static</code> lifetime.</p>
|
||
<p>We’ve made two changes in the body of the 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>Returning an <code>Err</code> value from <code>Config::build</code> allows the <code>main</code> function to
|
||
handle the <code>Result</code> value returned from the <code>build</code> function and exit the
|
||
process more cleanly in the error case.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="calling-confignew-and-handling-errors"></a></p>
|
||
<h4 id="calling-configbuild-and-handling-errors"><a class="header" href="#calling-configbuild-and-handling-errors">Calling <code>Config::build</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::build</code>, as shown in
|
||
Listing 12-10. We’ll also take the responsibility of exiting the command line
|
||
tool with a nonzero error code away from <code>panic!</code> and instead 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>
|
||
<figure class="listing" id="listing-12-10">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span>use std::process;
|
||
|
||
fn main() {
|
||
let args: Vec<String> = env::args().collect();
|
||
|
||
let config = Config::build(&args).unwrap_or_else(|err| {
|
||
println!("Problem parsing arguments: {err}");
|
||
process::exit(1);
|
||
});
|
||
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring"> println!("Searching for {}", config.query);
|
||
</span><span class="boring"> println!("In file {}", config.file_path);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let contents = fs::read_to_string(config.file_path)
|
||
</span><span class="boring"> .expect("Should have been able to read the file");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Config {
|
||
</span><span class="boring"> fn build(args: &[String]) -> Result<Config, &'static str> {
|
||
</span><span class="boring"> if args.len() < 3 {
|
||
</span><span class="boring"> return Err("not enough arguments");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let query = args[1].clone();
|
||
</span><span class="boring"> let file_path = args[2].clone();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Ok(Config { query, file_path })
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></code></pre>
|
||
<figcaption><a href="#listing-12-10">Listing 12-10</a>: Exiting with an error code if building a <code>Config</code> fails</figcaption>
|
||
</figure>
|
||
<p>In this listing, we’ve used a method we haven’t covered in detail yet:
|
||
<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 that <code>Ok</code> is wrapping. However, if the
|
||
value is an <code>Err</code> value, this method calls the code in the closure, which is
|
||
an anonymous function we define and pass as an argument to <code>unwrap_or_else</code>.
|
||
We’ll 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>We’ve 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. Let’s try it:</p>
|
||
<pre><code class="language-console">$ cargo run
|
||
Compiling minigrep v0.1.0 (file:///projects/minigrep)
|
||
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s
|
||
Running `target/debug/minigrep`
|
||
Problem parsing arguments: not enough arguments
|
||
</code></pre>
|
||
<p>Great! This output is much friendlier for our users.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="extracting-logic-from-the-main-function"></a></p>
|
||
<h3 id="extracting-logic-from-main"><a class="header" href="#extracting-logic-from-main">Extracting Logic from <code>main</code></a></h3>
|
||
<p>Now that we’ve finished refactoring the configuration parsing, let’s turn to
|
||
the program’s logic. As we stated in <a href="#separation-of-concerns-for-binary-projects">“Separating Concerns in Binary
|
||
Projects”</a><!-- ignore -->, we’ll
|
||
extract a function named <code>run</code> that will hold all the logic currently in the
|
||
<code>main</code> function that isn’t involved with setting up configuration or handling
|
||
errors. When we’re done, the <code>main</code> function will be concise and easy to verify
|
||
by inspection, and we’ll be able to write tests for all the other logic.</p>
|
||
<p>Listing 12-11 shows the small, incremental improvement of extracting a <code>run</code>
|
||
function.</p>
|
||
<figure class="listing" id="listing-12-11">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">use std::process;
|
||
</span><span class="boring">
|
||
</span>fn main() {
|
||
// --snip--
|
||
|
||
<span class="boring"> let args: Vec<String> = env::args().collect();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let config = Config::build(&args).unwrap_or_else(|err| {
|
||
</span><span class="boring"> println!("Problem parsing arguments: {err}");
|
||
</span><span class="boring"> process::exit(1);
|
||
</span><span class="boring"> });
|
||
</span><span class="boring">
|
||
</span> println!("Searching for {}", config.query);
|
||
println!("In file {}", config.file_path);
|
||
|
||
run(config);
|
||
}
|
||
|
||
fn run(config: Config) {
|
||
let contents = fs::read_to_string(config.file_path)
|
||
.expect("Should have been able to read the file");
|
||
|
||
println!("With text:\n{contents}");
|
||
}
|
||
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Config {
|
||
</span><span class="boring"> fn build(args: &[String]) -> Result<Config, &'static str> {
|
||
</span><span class="boring"> if args.len() < 3 {
|
||
</span><span class="boring"> return Err("not enough arguments");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let query = args[1].clone();
|
||
</span><span class="boring"> let file_path = args[2].clone();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Ok(Config { query, file_path })
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></code></pre>
|
||
<figcaption><a href="#listing-12-11">Listing 12-11</a>: Extracting a <code>run</code> function containing the rest of the program logic</figcaption>
|
||
</figure>
|
||
<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>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="returning-errors-from-the-run-function"></a></p>
|
||
<h4 id="returning-errors-from-run"><a class="header" href="#returning-errors-from-run">Returning Errors from <code>run</code></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::build</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 into <code>main</code> 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>
|
||
<figure class="listing" id="listing-12-12">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">use std::process;
|
||
</span>use std::error::Error;
|
||
|
||
// --snip--
|
||
|
||
<span class="boring">
|
||
</span><span class="boring">fn main() {
|
||
</span><span class="boring"> let args: Vec<String> = env::args().collect();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let config = Config::build(&args).unwrap_or_else(|err| {
|
||
</span><span class="boring"> println!("Problem parsing arguments: {err}");
|
||
</span><span class="boring"> process::exit(1);
|
||
</span><span class="boring"> });
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("Searching for {}", config.query);
|
||
</span><span class="boring"> println!("In file {}", config.file_path);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> run(config);
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>fn run(config: Config) -> Result<(), Box<dyn Error>> {
|
||
let contents = fs::read_to_string(config.file_path)?;
|
||
|
||
println!("With text:\n{contents}");
|
||
|
||
Ok(())
|
||
}
|
||
<span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Config {
|
||
</span><span class="boring"> fn build(args: &[String]) -> Result<Config, &'static str> {
|
||
</span><span class="boring"> if args.len() < 3 {
|
||
</span><span class="boring"> return Err("not enough arguments");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let query = args[1].clone();
|
||
</span><span class="boring"> let file_path = args[2].clone();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Ok(Config { query, file_path })
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></code></pre>
|
||
<figcaption><a href="#listing-12-12">Listing 12-12</a>: Changing the <code>run</code> function to return <code>Result</code></figcaption>
|
||
</figure>
|
||
<p>We’ve made three significant changes here. First, we changed the return type of
|
||
the <code>run</code> function to <code>Result<(), Box<dyn 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>
|
||
<p>For the error type, we used the trait object <code>Box<dyn Error></code> (and we brought
|
||
<code>std::error::Error</code> into scope with a <code>use</code> statement at the top). We’ll cover
|
||
trait objects in <a href="ch18-00-oop.html">Chapter 18</a><!-- ignore -->. For now, just know that
|
||
<code>Box<dyn 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. The <code>dyn</code> keyword is short for
|
||
<em>dynamic</em>.</p>
|
||
<p>Second, we’ve 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.
|
||
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 might 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 code, it will compile but will display a warning:</p>
|
||
<pre><code class="language-console">$ cargo run -- the poem.txt
|
||
Compiling minigrep v0.1.0 (file:///projects/minigrep)
|
||
warning: unused `Result` that must be used
|
||
--> src/main.rs:19:5
|
||
|
|
||
19 | run(config);
|
||
| ^^^^^^^^^^^
|
||
|
|
||
= note: this `Result` may be an `Err` variant, which should be handled
|
||
= note: `#[warn(unused_must_use)]` on by default
|
||
help: use `let _ = ...` to ignore the resulting value
|
||
|
|
||
19 | let _ = run(config);
|
||
| +++++++
|
||
|
||
warning: `minigrep` (bin "minigrep") generated 1 warning
|
||
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.71s
|
||
Running `target/debug/minigrep the poem.txt`
|
||
Searching for the
|
||
In file poem.txt
|
||
With text:
|
||
I'm nobody! Who are you?
|
||
Are you nobody, too?
|
||
Then there's a pair of us - don't tell!
|
||
They'd banish us, you know.
|
||
|
||
How dreary to be somebody!
|
||
How public, like a frog
|
||
To tell your name the livelong day
|
||
To an admiring bog!
|
||
|
||
</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 we’re 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! Let’s rectify that problem now.</p>
|
||
<h4 id="handling-errors-returned-from-run-in-main"><a class="header" href="#handling-errors-returned-from-run-in-main">Handling Errors Returned from <code>run</code> in <code>main</code></a></h4>
|
||
<p>We’ll check for errors and handle them using a technique similar to one we used
|
||
with <code>Config::build</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"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::error::Error;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">use std::process;
|
||
</span><span class="boring">
|
||
</span>fn main() {
|
||
// --snip--
|
||
|
||
<span class="boring"> let args: Vec<String> = env::args().collect();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let config = Config::build(&args).unwrap_or_else(|err| {
|
||
</span><span class="boring"> println!("Problem parsing arguments: {err}");
|
||
</span><span class="boring"> process::exit(1);
|
||
</span><span class="boring"> });
|
||
</span><span class="boring">
|
||
</span> println!("Searching for {}", config.query);
|
||
println!("In file {}", config.file_path);
|
||
|
||
if let Err(e) = run(config) {
|
||
println!("Application error: {e}");
|
||
process::exit(1);
|
||
}
|
||
}
|
||
<span class="boring">
|
||
</span><span class="boring">fn run(config: Config) -> Result<(), Box<dyn Error>> {
|
||
</span><span class="boring"> let contents = fs::read_to_string(config.file_path)?;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> println!("With text:\n{contents}");
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Ok(())
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Config {
|
||
</span><span class="boring"> fn build(args: &[String]) -> Result<Config, &'static str> {
|
||
</span><span class="boring"> if args.len() < 3 {
|
||
</span><span class="boring"> return Err("not enough arguments");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let query = args[1].clone();
|
||
</span><span class="boring"> let file_path = args[2].clone();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Ok(Config { query, file_path })
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></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 to call <code>process::exit(1)</code> if it does. The <code>run</code> function
|
||
doesn’t return a value that we want to <code>unwrap</code> in the same way that
|
||
<code>Config::build</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 don’t need
|
||
<code>unwrap_or_else</code> to return the unwrapped value, which 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 id="splitting-code-into-a-library-crate"><a class="header" href="#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 we’ll split the
|
||
<em>src/main.rs</em> file and put some code into the <em>src/lib.rs</em> file. That way, we
|
||
can test the code and have a <em>src/main.rs</em> file with fewer responsibilities.</p>
|
||
<p>Let’s define the code responsible for searching text in <em>src/lib.rs</em> rather
|
||
than in <em>src/main.rs</em>, which will let us (or anyone else using our
|
||
<code>minigrep</code> library) call the searching function from more contexts than our
|
||
<code>minigrep</code> binary.</p>
|
||
<p>First, let’s define the <code>search</code> function signature in <em>src/lib.rs</em> as shown in
|
||
Listing 12-13, with a body that calls the <code>unimplemented!</code> macro. We’ll explain
|
||
the signature in more detail when we fill in the implementation.</p>
|
||
<figure class="listing" id="listing-12-13">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile">pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
|
||
unimplemented!();
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-12-13">Listing 12-13</a>: Defining the <code>search</code> function in <em>src/lib.rs</em></figcaption>
|
||
</figure>
|
||
<p>We’ve used the <code>pub</code> keyword on the function definition to designate <code>search</code>
|
||
as part of our library crate’s public API. We now have a library crate that we
|
||
can use from our binary crate and that we can test!</p>
|
||
<p>Now we need to bring the code defined in <em>src/lib.rs</em> into the scope of the
|
||
binary crate in <em>src/main.rs</em> and call it, as shown in Listing 12-14.</p>
|
||
<figure class="listing" id="listing-12-14">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use std::env;
|
||
</span><span class="boring">use std::error::Error;
|
||
</span><span class="boring">use std::fs;
|
||
</span><span class="boring">use std::process;
|
||
</span><span class="boring">
|
||
</span>// --snip--
|
||
use minigrep::search;
|
||
|
||
fn main() {
|
||
// --snip--
|
||
<span class="boring"> let args: Vec<String> = env::args().collect();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let config = Config::build(&args).unwrap_or_else(|err| {
|
||
</span><span class="boring"> println!("Problem parsing arguments: {err}");
|
||
</span><span class="boring"> process::exit(1);
|
||
</span><span class="boring"> });
|
||
</span><span class="boring">
|
||
</span><span class="boring"> if let Err(e) = run(config) {
|
||
</span><span class="boring"> println!("Application error: {e}");
|
||
</span><span class="boring"> process::exit(1);
|
||
</span><span class="boring"> }
|
||
</span>}
|
||
|
||
// --snip--
|
||
|
||
<span class="boring">
|
||
</span><span class="boring">struct Config {
|
||
</span><span class="boring"> query: String,
|
||
</span><span class="boring"> file_path: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Config {
|
||
</span><span class="boring"> fn build(args: &[String]) -> Result<Config, &'static str> {
|
||
</span><span class="boring"> if args.len() < 3 {
|
||
</span><span class="boring"> return Err("not enough arguments");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let query = args[1].clone();
|
||
</span><span class="boring"> let file_path = args[2].clone();
|
||
</span><span class="boring">
|
||
</span><span class="boring"> Ok(Config { query, file_path })
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>fn run(config: Config) -> Result<(), Box<dyn Error>> {
|
||
let contents = fs::read_to_string(config.file_path)?;
|
||
|
||
for line in search(&config.query, &contents) {
|
||
println!("{line}");
|
||
}
|
||
|
||
Ok(())
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-12-14">Listing 12-14</a>: Using the <code>minigrep</code> library crate’s <code>search</code> function in <em>src/main.rs</em></figcaption>
|
||
</figure>
|
||
<p>We add a <code>use minigrep::search</code> line to bring the <code>search</code> function from
|
||
the library crate into the binary crate’s scope. Then, in the <code>run</code> function,
|
||
rather than printing out the contents of the file, we call the <code>search</code>
|
||
function and pass the <code>config.query</code> value and <code>contents</code> as arguments. Then,
|
||
<code>run</code> will use a <code>for</code> loop to print each line returned from <code>search</code> that
|
||
matched the query. This is also a good time to remove the <code>println!</code> calls in
|
||
the <code>main</code> function that displayed the query and the file path so that our
|
||
program only prints the search results (if no errors occur).</p>
|
||
<p>Note that the search function will be collecting all the results into a vector
|
||
it returns before any printing happens. This implementation could be slow to
|
||
display results when searching large files, because results aren’t printed as
|
||
they’re found; we’ll discuss a possible way to fix this using iterators in
|
||
Chapter 13.</p>
|
||
<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 the 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 difficult with the old code but is easy with the new code: We’ll
|
||
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">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M41.4 233.4c-12.5 12.5-12.5 32.8 0 45.3l160 160c12.5 12.5 32.8 12.5 45.3 0s12.5-32.8 0-45.3L109.3 256 246.6 118.6c12.5-12.5 12.5-32.8 0-45.3s-32.8-12.5-45.3 0l-160 160z"/></svg></span>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="ch12-04-testing-the-librarys-functionality.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M278.6 233.4c12.5 12.5 12.5 32.8 0 45.3l-160 160c-12.5 12.5-32.8 12.5-45.3 0s-12.5-32.8 0-45.3L210.7 256 73.4 118.6c-12.5-12.5-12.5-32.8 0-45.3s32.8-12.5 45.3 0l160 160z"/></svg></span>
|
||
</a>
|
||
|
||
<div style="clear: both"></div>
|
||
</nav>
|
||
</div>
|
||
</div>
|
||
|
||
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
||
<a rel="prev" href="ch12-02-reading-a-file.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M41.4 233.4c-12.5 12.5-12.5 32.8 0 45.3l160 160c12.5 12.5 32.8 12.5 45.3 0s12.5-32.8 0-45.3L109.3 256 246.6 118.6c12.5-12.5 12.5-32.8 0-45.3s-32.8-12.5-45.3 0l-160 160z"/></svg></span>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="ch12-04-testing-the-librarys-functionality.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M278.6 233.4c12.5 12.5 12.5 32.8 0 45.3l-160 160c-12.5 12.5-32.8 12.5-45.3 0s-12.5-32.8 0-45.3L210.7 256 73.4 118.6c-12.5-12.5-12.5-32.8 0-45.3s32.8-12.5 45.3 0l160 160z"/></svg></span>
|
||
</a>
|
||
</nav>
|
||
|
||
</div>
|
||
|
||
<template id=fa-eye><span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 576 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M288 32c-80.8 0-145.5 36.8-192.6 80.6C48.6 156 17.3 208 2.5 243.7c-3.3 7.9-3.3 16.7 0 24.6C17.3 304 48.6 356 95.4 399.4C142.5 443.2 207.2 480 288 480s145.5-36.8 192.6-80.6c46.8-43.5 78.1-95.4 93-131.1c3.3-7.9 3.3-16.7 0-24.6c-14.9-35.7-46.2-87.7-93-131.1C433.5 68.8 368.8 32 288 32zM432 256c0 79.5-64.5 144-144 144s-144-64.5-144-144s64.5-144 144-144s144 64.5 144 144zM288 192c0 35.3-28.7 64-64 64c-11.5 0-22.3-3-31.6-8.4c-.2 2.8-.4 5.5-.4 8.4c0 53 43 96 96 96s96-43 96-96s-43-96-96-96c-2.8 0-5.6 .1-8.4 .4c5.3 9.3 8.4 20.1 8.4 31.6z"/></svg></span></template>
|
||
<template id=fa-eye-slash><span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M38.8 5.1C28.4-3.1 13.3-1.2 5.1 9.2S-1.2 34.7 9.2 42.9l592 464c10.4 8.2 25.5 6.3 33.7-4.1s6.3-25.5-4.1-33.7L525.6 386.7c39.6-40.6 66.4-86.1 79.9-118.4c3.3-7.9 3.3-16.7 0-24.6c-14.9-35.7-46.2-87.7-93-131.1C465.5 68.8 400.8 32 320 32c-68.2 0-125 26.3-169.3 60.8L38.8 5.1zM223.1 149.5C248.6 126.2 282.7 112 320 112c79.5 0 144 64.5 144 144c0 24.9-6.3 48.3-17.4 68.7L408 294.5c5.2-11.8 8-24.8 8-38.5c0-53-43-96-96-96c-2.8 0-5.6 .1-8.4 .4c5.3 9.3 8.4 20.1 8.4 31.6c0 10.2-2.4 19.8-6.6 28.3l-90.3-70.8zm223.1 298L373 389.9c-16.4 6.5-34.3 10.1-53 10.1c-79.5 0-144-64.5-144-144c0-6.9 .5-13.6 1.4-20.2L83.1 161.5C60.3 191.2 44 220.8 34.5 243.7c-3.3 7.9-3.3 16.7 0 24.6c14.9 35.7 46.2 87.7 93 131.1C174.5 443.2 239.2 480 320 480c47.8 0 89.9-12.9 126.2-32.5z"/></svg></span></template>
|
||
<template id=fa-copy><span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M502.6 70.63l-61.25-61.25C435.4 3.371 427.2 0 418.7 0H255.1c-35.35 0-64 28.66-64 64l.0195 256C192 355.4 220.7 384 256 384h192c35.2 0 64-28.8 64-64V93.25C512 84.77 508.6 76.63 502.6 70.63zM464 320c0 8.836-7.164 16-16 16H255.1c-8.838 0-16-7.164-16-16L239.1 64.13c0-8.836 7.164-16 16-16h128L384 96c0 17.67 14.33 32 32 32h47.1V320zM272 448c0 8.836-7.164 16-16 16H63.1c-8.838 0-16-7.164-16-16L47.98 192.1c0-8.836 7.164-16 16-16H160V128H63.99c-35.35 0-64 28.65-64 64l.0098 256C.002 483.3 28.66 512 64 512h192c35.2 0 64-28.8 64-64v-32h-47.1L272 448z"/></svg></span></template>
|
||
<template id=fa-play><span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 384 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M73 39c-14.8-9.1-33.4-9.4-48.5-.9S0 62.6 0 80V432c0 17.4 9.4 33.4 24.5 41.9s33.7 8.1 48.5-.9L361 297c14.3-8.7 23-24.2 23-41s-8.7-32.2-23-41L73 39z"/></svg></span></template>
|
||
<template id=fa-clock-rotate-left><span class=fa-svg><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 6.2.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2022 Fonticons, Inc. --><path d="M75 75L41 41C25.9 25.9 0 36.6 0 57.9V168c0 13.3 10.7 24 24 24H134.1c21.4 0 32.1-25.9 17-41l-30.8-30.8C155 85.5 203 64 256 64c106 0 192 86 192 192s-86 192-192 192c-40.8 0-78.6-12.7-109.7-34.4c-14.5-10.1-34.4-6.6-44.6 7.9s-6.6 34.4 7.9 44.6C151.2 495 201.7 512 256 512c141.4 0 256-114.6 256-256S397.4 0 256 0C185.3 0 121.3 28.7 75 75zm181 53c-13.3 0-24 10.7-24 24V256c0 6.4 2.5 12.5 7 17l72 72c9.4 9.4 24.6 9.4 33.9 0s9.4-24.6 0-33.9l-65-65V152c0-13.3-10.7-24-24-24z"/></svg></span></template>
|
||
|
||
|
||
|
||
<script>
|
||
window.playground_copyable = true;
|
||
</script>
|
||
|
||
|
||
<script src="elasticlunr-ef4e11c1.min.js"></script>
|
||
<script src="mark-09e88c2c.min.js"></script>
|
||
<script src="searcher-09f2665d.js"></script>
|
||
|
||
<script src="clipboard-1626706a.min.js"></script>
|
||
<script src="highlight-abc7f01d.js"></script>
|
||
<script src="book-c22b7243.js"></script>
|
||
|
||
<!-- Custom JS scripts -->
|
||
<script src="ferris-2317480c.js"></script>
|
||
|
||
|
||
|
||
</div>
|
||
</body>
|
||
</html>
|