<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-scale=1">

<title>Bugs and Errors :: Eloquent JavaScript</title>

<link rel=stylesheet href="js/node_modules/codemirror/lib/codemirror.css">

<script src="js/acorn_codemirror.js"></script>

<link rel=stylesheet href="css/ejs.css">

<script src="js/sandbox.js"></script>

<script src="js/ejs.js"></script><script>var chapNum = 8;var sandboxLoadFiles = ["code/chapter/08_error.js"];</script></head>

<nav><a href="07_robot.html" title="previous chapter">◀</a> <a href="index.html" title="cover">◆</a> <a href="09_regexp.html" title="next chapter">▶</a></nav>

<h1><span class=chap_num>Chapter 8</span>Bugs and Errors</h1>

<p><a class="p_ident" id="p_tsWlII94Rs" href="#p_tsWlII94Rs" tabindex="-1" role="presentation"></a>Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.</p>

<footer>Brian Kernighan and P.J. Plauger, <cite>The Elements of Programming Style</cite></footer>

</blockquote><figure class="chapter framed"><img src="img/chapter_picture_8.jpg" alt="Picture of a collection of bugs"></figure>

<p><a class="p_ident" id="p_O+MttnhYVC" href="#p_O+MttnhYVC" tabindex="-1" role="presentation"></a>Flaws in computer programs are usually called <em>bugs</em>. It makes programmers feel good to imagine them as little things that just happen to crawl into our work. In reality, of course, we put them there ourselves.</p>

<p><a class="p_ident" id="p_bcWk0EwGpY" href="#p_bcWk0EwGpY" tabindex="-1" role="presentation"></a>If a program is crystallized thought, you can roughly categorize bugs into those caused by the thoughts being confused and those caused by mistakes introduced while converting a thought to code. The former type is generally harder to diagnose and fix than the latter.</p>

<h2><a class="h_ident" id="h_ibhqsOZvUn" href="#h_ibhqsOZvUn" tabindex="-1" role="presentation"></a>Language</h2>

<p><a class="p_ident" id="p_ye1ml09vBV" href="#p_ye1ml09vBV" tabindex="-1" role="presentation"></a>Many mistakes could be pointed out to us automatically by the computer, if it knew enough about what we’re trying to do. But here JavaScript’s looseness is a hindrance. Its concept of bindings and properties is vague enough that it will rarely catch typos before actually running the program. And even then, it allows you to do some clearly nonsensical things without complaint, such as computing <code>true * &quot;monkey&quot;</code>.</p>

<p><a class="p_ident" id="p_EcSg7P4I9E" href="#p_EcSg7P4I9E" tabindex="-1" role="presentation"></a>There are some things that JavaScript does complain about. Writing a program that does not follow the language’s grammar will immediately make the computer complain. Other things, such as calling something that’s not a function or looking up a property on an undefined value, will cause an error to be reported when the program tries to perform the action.</p>

<p><a class="p_ident" id="p_M/fMASXkeH" href="#p_M/fMASXkeH" tabindex="-1" role="presentation"></a>But often, your nonsense computation will merely produce <code>NaN</code> (not a number) or an undefined value, while the program happily continues, convinced that it’s doing something meaningful. The mistake will manifest itself only later, after the bogus value has traveled through several functions. It might not trigger an error at all but silently cause the program’s output to be wrong. Finding the source of such problems can be difficult.</p>

<p><a class="p_ident" id="p_LaAYmHSV12" href="#p_LaAYmHSV12" tabindex="-1" role="presentation"></a>The process of finding mistakes—bugs—in programs is called <em>debugging</em>.</p>

<h2><a class="h_ident" id="h_u1jlTq3i42" href="#h_u1jlTq3i42" tabindex="-1" role="presentation"></a>Strict mode</h2>

<p><a class="p_ident" id="p_WJCaiNx5iy" href="#p_WJCaiNx5iy" tabindex="-1" role="presentation"></a>JavaScript can be made a <em>little</em> stricter by enabling <em>strict mode</em>. This is done by putting the string <code>&quot;use strict&quot;</code> at the top of a file or a function body. Here’s an example:</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_tKCBneE0vw" href="#c_tKCBneE0vw" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">canYouSpotTheProblem</span>() {

<span class="cm-string">&quot;use strict&quot;</span>;

<span class="cm-keyword">for</span> (<span class="cm-variable">counter</span> <span class="cm-operator">=</span> <span class="cm-number">0</span>; <span class="cm-variable">counter</span> <span class="cm-operator">&lt;</span> <span class="cm-number">10</span>; <span class="cm-variable">counter</span><span class="cm-operator">++</span>) {

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-string">&quot;Happy happy&quot;</span>);

}

}

<span class="cm-variable">canYouSpotTheProblem</span>();

<span class="cm-comment">// → ReferenceError: counter is not defined</span></pre>

<p><a class="p_ident" id="p_9RL+1s9Y4+" href="#p_9RL+1s9Y4+" tabindex="-1" role="presentation"></a>Normally, when you forget to put <code>let</code> in front of your binding, as with <code>counter</code> in the example, JavaScript quietly creates a global binding and uses that. In strict mode, an error is reported instead. This is very helpful. It should be noted, though, that this doesn’t work when the binding in question already exists as a global binding. In that case, the loop will still quietly overwrite the value of the binding.</p>

<p><a class="p_ident" id="p_WqXHKWNRd1" href="#p_WqXHKWNRd1" tabindex="-1" role="presentation"></a>Another change in strict mode is that the <code>this</code> binding holds the value <code>undefined</code> in functions that are not called as methods. When making such a call outside of strict mode, <code>this</code> refers to the global scope object, which is an object whose properties are the global bindings. So if you accidentally call a method or constructor incorrectly in strict mode, JavaScript will produce an error as soon as it tries to read something from <code>this</code>, rather than happily writing to the global scope.</p>

<p><a class="p_ident" id="p_eZSU5aTSD4" href="#p_eZSU5aTSD4" tabindex="-1" role="presentation"></a>For example, consider the following code, which calls a constructor function without the <code>new</code> keyword so that its <code>this</code> will <em>not</em> refer to a newly constructed object:</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_FPKrb2F1C3" href="#c_FPKrb2F1C3" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">Person</span>(<span class="cm-def">name</span>) { <span class="cm-keyword">this</span>.<span class="cm-property">name</span> <span class="cm-operator">=</span> <span class="cm-variable-2">name</span>; }

<span class="cm-keyword">let</span> <span class="cm-def">ferdinand</span> <span class="cm-operator">=</span> <span class="cm-variable">Person</span>(<span class="cm-string">&quot;Ferdinand&quot;</span>); <span class="cm-comment">// oops</span>

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-variable">name</span>);

<span class="cm-comment">// → Ferdinand</span></pre>

<p><a class="p_ident" id="p_Tv3LlrrZaj" href="#p_Tv3LlrrZaj" tabindex="-1" role="presentation"></a>So the bogus call to <code>Person</code> succeeded but returned an undefined value and created the global binding <code>name</code>. In strict mode, the result is different.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_HFy5dGOOh4" href="#c_HFy5dGOOh4" tabindex="-1" role="presentation"></a><span class="cm-string">&quot;use strict&quot;</span>;

<span class="cm-keyword">function</span> <span class="cm-def">Person</span>(<span class="cm-def">name</span>) { <span class="cm-keyword">this</span>.<span class="cm-property">name</span> <span class="cm-operator">=</span> <span class="cm-variable-2">name</span>; }

<span class="cm-keyword">let</span> <span class="cm-def">ferdinand</span> <span class="cm-operator">=</span> <span class="cm-variable">Person</span>(<span class="cm-string">&quot;Ferdinand&quot;</span>); <span class="cm-comment">// forgot new</span>

<span class="cm-comment">// → TypeError: Cannot set property 'name' of undefined</span></pre>

<p><a class="p_ident" id="p_0eYPyoGi1l" href="#p_0eYPyoGi1l" tabindex="-1" role="presentation"></a>We are immediately told that something is wrong. This is helpful.</p>

<p><a class="p_ident" id="p_WGJIyAOZ/i" href="#p_WGJIyAOZ/i" tabindex="-1" role="presentation"></a>Fortunately, constructors created with the <code>class</code> notation will always complain if they are called without <code>new</code>, making this less of a problem even in non-strict mode.</p>

<p><a class="p_ident" id="p_qlYTT6nRD4" href="#p_qlYTT6nRD4" tabindex="-1" role="presentation"></a>Strict mode does a few more things. It disallows giving a function multiple parameters with the same name and removes certain problematic language features entirely (such as the <code>with</code> statement, which is so wrong it is not further discussed in this book).</p>

<p><a class="p_ident" id="p_kIUErMqROW" href="#p_kIUErMqROW" tabindex="-1" role="presentation"></a>In short, putting <code>&quot;use strict&quot;</code> at the top of your program rarely hurts and might help you spot a problem.</p>

<h2><a class="h_ident" id="h_k7niieKEJG" href="#h_k7niieKEJG" tabindex="-1" role="presentation"></a>Types</h2>

<p><a class="p_ident" id="p_YhTIyNZyz8" href="#p_YhTIyNZyz8" tabindex="-1" role="presentation"></a>Some languages want to know the types of all your bindings and expressions before even running a program. They will tell you right away when a type is used in an inconsistent way. JavaScript considers types only when actually running the program, and even there often tries to implicitly convert values to the type it expects, so it’s not much help.</p>

<p><a class="p_ident" id="p_YdtQydcPrv" href="#p_YdtQydcPrv" tabindex="-1" role="presentation"></a>Still, types provide a useful framework for talking about programs. A lot of mistakes come from being confused about the kind of value that goes into or comes out of a function. If you have that information written down, you’re less likely to get confused.</p>

<p><a class="p_ident" id="p_YSuG1qtqyR" href="#p_YSuG1qtqyR" tabindex="-1" role="presentation"></a>You could add a comment like the following before the <code>goalOrientedRobot</code> function from the previous chapter to describe its type:</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_30eJTz3eQP" href="#c_30eJTz3eQP" tabindex="-1" role="presentation"></a><span class="cm-comment">// (VillageState, Array) → {direction: string, memory: Array}</span>

<span class="cm-keyword">function</span> <span class="cm-def">goalOrientedRobot</span>(<span class="cm-def">state</span>, <span class="cm-def">memory</span>) {

<span class="cm-comment">// ...</span>

}</pre>

<p><a class="p_ident" id="p_wRx2hJtLds" href="#p_wRx2hJtLds" tabindex="-1" role="presentation"></a>There are a number of different conventions for annotating JavaScript programs with types.</p>

<p><a class="p_ident" id="p_K+Rg+L+z0T" href="#p_K+Rg+L+z0T" tabindex="-1" role="presentation"></a>One thing about types is that they need to introduce their own complexity to be able to describe enough code to be useful. What do you think would be the type of the <code>randomPick</code> function that returns a random element from an array? You’d need to introduce a <em>type

variable</em>, <em>T</em>, which can stand in for any type, so that you can give <code>randomPick</code> a type like <code>([T]) → T</code> (function from an array of <em>T</em>s to a <em>T</em>).</p>

<p id="typing"><a class="p_ident" id="p_eztjw3zFDU" href="#p_eztjw3zFDU" tabindex="-1" role="presentation"></a>When the types of a program are known, it is possible for the computer to <em>check</em> them for you, pointing out mistakes before the program is run. There are several JavaScript dialects that add types to the language and check them. The most popular one is called <a href="https://www.typescriptlang.org/">TypeScript</a>. If you are interested in adding more rigor to your programs, I recommend you give it a try.</p>

<p><a class="p_ident" id="p_t8esQrTIP9" href="#p_t8esQrTIP9" tabindex="-1" role="presentation"></a>In this book, we’ll continue using raw, dangerous, untyped JavaScript code.</p>

<h2><a class="h_ident" id="h_CCCzKyBrc1" href="#h_CCCzKyBrc1" tabindex="-1" role="presentation"></a>Testing</h2>

<p><a class="p_ident" id="p_cfHj2WfM1O" href="#p_cfHj2WfM1O" tabindex="-1" role="presentation"></a>If the language is not going to do much to help us find mistakes, we’ll have to find them the hard way: by running the program and seeing whether it does the right thing.</p>

<p><a class="p_ident" id="p_8W1dLTf8k6" href="#p_8W1dLTf8k6" tabindex="-1" role="presentation"></a>Doing this by hand, again and again, is a really bad idea. Not only is it annoying, it also tends to be ineffective since it takes too much time to exhaustively test everything every time you make a change.</p>

<p><a class="p_ident" id="p_ngk+1LWoAU" href="#p_ngk+1LWoAU" tabindex="-1" role="presentation"></a>Computers are good at repetitive tasks, and testing is the ideal repetitive task. Automated testing is the process of writing a program that tests another program. Writing tests is a bit more work than testing manually, but once you’ve done it, you gain a kind of superpower: it takes you only a few seconds to verify that your program still behaves properly in all the situations you wrote tests for. When you break something, you’ll immediately notice, rather than randomly running into it at some later time.</p>

<p><a class="p_ident" id="p_S/z0iwnHlS" href="#p_S/z0iwnHlS" tabindex="-1" role="presentation"></a>Tests usually take the form of little labeled programs that verify some aspect of your code. For example, a set of tests for the (standard, probably already tested by someone else) <code>toUpperCase</code> method might look like this:</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_WrGyqyPbp3" href="#c_WrGyqyPbp3" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">test</span>(<span class="cm-def">label</span>, <span class="cm-def">body</span>) {

<span class="cm-keyword">if</span> (<span class="cm-operator">!</span><span class="cm-variable-2">body</span>()) <span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-string-2">`Failed: ${</span><span class="cm-variable-2">label</span><span class="cm-string-2">}</span><span class="cm-string-2">`</span>);

}

<span class="cm-variable">test</span>(<span class="cm-string">&quot;convert Latin text to uppercase&quot;</span>, () <span class="cm-operator">=&gt;</span> {

<span class="cm-keyword">return</span> <span class="cm-string">&quot;hello&quot;</span>.<span class="cm-property">toUpperCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;HELLO&quot;</span>;

});

<span class="cm-variable">test</span>(<span class="cm-string">&quot;convert Greek text to uppercase&quot;</span>, () <span class="cm-operator">=&gt;</span> {

<span class="cm-keyword">return</span> <span class="cm-string">&quot;Χαίρετε&quot;</span>.<span class="cm-property">toUpperCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;ΧΑΊΡΕΤΕ&quot;</span>;

});

<span class="cm-variable">test</span>(<span class="cm-string">&quot;don't convert case-less characters&quot;</span>, () <span class="cm-operator">=&gt;</span> {

<span class="cm-keyword">return</span> <span class="cm-string">&quot;مرحبا&quot;</span>.<span class="cm-property">toUpperCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;مرحبا&quot;</span>;

});</pre>

<p><a class="p_ident" id="p_Gyas+RfY6l" href="#p_Gyas+RfY6l" tabindex="-1" role="presentation"></a>Writing tests like this tends to produce rather repetitive, awkward code. Fortunately, there exist pieces of software that help you build and run collections of tests (<em>test suites</em>) by providing a language (in the form of functions and methods) suited to expressing tests and by outputting informative information when a test fails. These are usually called <em>test runners</em>.</p>

<p><a class="p_ident" id="p_zmvP6RI0eK" href="#p_zmvP6RI0eK" tabindex="-1" role="presentation"></a>Some code is easier to test than other code. Generally, the more external objects that the code interacts with, the harder it is to set up the context in which to test it. The style of programming shown in the <a href="07_robot.html">previous chapter</a>, which uses self-contained persistent values rather than changing objects, tends to be easy to test.</p>

<h2><a class="h_ident" id="h_iVsnyIAWUT" href="#h_iVsnyIAWUT" tabindex="-1" role="presentation"></a>Debugging</h2>

<p><a class="p_ident" id="p_5mME8LB07m" href="#p_5mME8LB07m" tabindex="-1" role="presentation"></a>Once you notice there is something wrong with your program because it misbehaves or produces errors, the next step is to figure out <em>what</em> the problem is.</p>

<p><a class="p_ident" id="p_CJKevweHV6" href="#p_CJKevweHV6" tabindex="-1" role="presentation"></a>Sometimes it is obvious. The error message will point at a specific line of your program, and if you look at the error description and that line of code, you can often see the problem.</p>

<p><a class="p_ident" id="p_5SwXZX1qh1" href="#p_5SwXZX1qh1" tabindex="-1" role="presentation"></a>But not always. Sometimes the line that triggered the problem is simply the first place where a flaky value produced elsewhere gets used in an invalid way. If you have been solving the exercises in earlier chapters, you will probably have already experienced such situations.</p>

<p><a class="p_ident" id="p_rsq5hJyXKX" href="#p_rsq5hJyXKX" tabindex="-1" role="presentation"></a>The following example program tries to convert a whole number to a string in a given base (decimal, binary, and so on) by repeatedly picking out the last digit and then dividing the number to get rid of this digit. But the strange output that it currently produces suggests that it has a bug.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_8tOR9x4PzT" href="#c_8tOR9x4PzT" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">numberToString</span>(<span class="cm-def">n</span>, <span class="cm-def">base</span> <span class="cm-operator">=</span> <span class="cm-number">10</span>) {

<span class="cm-keyword">let</span> <span class="cm-def">result</span> <span class="cm-operator">=</span> <span class="cm-string">&quot;&quot;</span>, <span class="cm-def">sign</span> <span class="cm-operator">=</span> <span class="cm-string">&quot;&quot;</span>;

<span class="cm-keyword">if</span> (<span class="cm-variable-2">n</span> <span class="cm-operator">&lt;</span> <span class="cm-number">0</span>) {

<span class="cm-variable-2">sign</span> <span class="cm-operator">=</span> <span class="cm-string">&quot;-&quot;</span>;

<span class="cm-variable-2">n</span> <span class="cm-operator">=</span> <span class="cm-operator">-</span><span class="cm-variable-2">n</span>;

}

<span class="cm-keyword">do</span> {

<span class="cm-variable-2">result</span> <span class="cm-operator">=</span> <span class="cm-variable">String</span>(<span class="cm-variable-2">n</span> <span class="cm-operator">%</span> <span class="cm-variable-2">base</span>) <span class="cm-operator">+</span> <span class="cm-variable-2">result</span>;

<span class="cm-variable-2">n</span> <span class="cm-operator">/=</span> <span class="cm-variable-2">base</span>;

} <span class="cm-keyword">while</span> (<span class="cm-variable-2">n</span> <span class="cm-operator">&gt;</span> <span class="cm-number">0</span>);

<span class="cm-keyword">return</span> <span class="cm-variable-2">sign</span> <span class="cm-operator">+</span> <span class="cm-variable-2">result</span>;

}

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-variable">numberToString</span>(<span class="cm-number">13</span>, <span class="cm-number">10</span>));

<span class="cm-comment">// → 1.5e-3231.3e-3221.3e-3211.3e-3201.3e-3191.3e-3181.3…</span></pre>

<p><a class="p_ident" id="p_KiDfjUS51F" href="#p_KiDfjUS51F" tabindex="-1" role="presentation"></a>Even if you see the problem already, pretend for a moment that you don’t. We know that our program is malfunctioning, and we want to find out why.</p>

<p><a class="p_ident" id="p_2OJsjnmKOW" href="#p_2OJsjnmKOW" tabindex="-1" role="presentation"></a>This is where you must resist the urge to start making random changes to the code to see whether that makes it better. Instead, <em>think</em>. Analyze what is happening and come up with a theory of why it might be happening. Then, make additional observations to test this theory—or, if you don’t yet have a theory, make additional observations to help you come up with one.</p>

<p><a class="p_ident" id="p_HuAniqpAd5" href="#p_HuAniqpAd5" tabindex="-1" role="presentation"></a>Putting a few strategic <code>console.log</code> calls into the program is a good way to get additional information about what the program is doing. In this case, we want <code>n</code> to take the values <code>13</code>, <code>1</code>, and then <code>0</code>. Let’s write out its value at the start of the loop.</p>

<pre class="snippet cm-s-default" data-language="null" ><a class="c_ident" id="c_nB/OeL8UNa" href="#c_nB/OeL8UNa" tabindex="-1" role="presentation"></a>13

1.3

0.13

0.013

…

1.5e-323</pre>

<p><a class="p_ident" id="p_I+PNN6aJ0e" href="#p_I+PNN6aJ0e" tabindex="-1" role="presentation"></a><em>Right</em>. Dividing 13 by 10 does not produce a whole number. Instead of <code>n /= base</code>, what we actually want is <code>n = Math.<wbr>floor(n /<wbr> base)</code> so that the number is properly “shifted” to the right.</p>

<p><a class="p_ident" id="p_0eFcPpir7M" href="#p_0eFcPpir7M" tabindex="-1" role="presentation"></a>An alternative to using <code>console.log</code> to peek into the program’s behavior is to use the <em>debugger</em> capabilities of your browser. Browsers come with the ability to set a <em>breakpoint</em> on a specific line of your code. When the execution of the program reaches a line with a breakpoint, it is paused, and you can inspect the values of bindings at that point. I won’t go into details, as debuggers differ from browser to browser, but look in your browser’s developer

tools or search the Web for more information.</p>

<p><a class="p_ident" id="p_h2R9jlfw7o" href="#p_h2R9jlfw7o" tabindex="-1" role="presentation"></a>Another way to set a breakpoint is to include a <code>debugger</code> statement (consisting of simply that keyword) in your program. If the developer tools of your browser are active, the program will pause whenever it reaches such a statement.</p>

<h2><a class="h_ident" id="h_iwwPbaBjJD" href="#h_iwwPbaBjJD" tabindex="-1" role="presentation"></a>Error propagation</h2>

<p><a class="p_ident" id="p_cHc7tL2ujS" href="#p_cHc7tL2ujS" tabindex="-1" role="presentation"></a>Not all problems can be prevented by the programmer, unfortunately. If your program communicates with the outside world in any way, it is possible to get malformed input, to become overloaded with work, or to have the network fail.</p>

<p><a class="p_ident" id="p_zy372pQBzA" href="#p_zy372pQBzA" tabindex="-1" role="presentation"></a>If you’re programming only for yourself, you can afford to just ignore such problems until they occur. But if you build something that is going to be used by anybody else, you usually want the program to do better than just crash. Sometimes the right thing to do is take the bad input in stride and continue running. In other cases, it is better to report to the user what went wrong and then give up. But in either situation, the program has to actively do something in response to the problem.</p>

<p><a class="p_ident" id="p_ZrDi3JVFsJ" href="#p_ZrDi3JVFsJ" tabindex="-1" role="presentation"></a>Say you have a function <code>promptNumber</code> that asks the user for a number and returns it. What should it return if the user inputs “orange”?</p>

<p><a class="p_ident" id="p_ee4d/K1Bh5" href="#p_ee4d/K1Bh5" tabindex="-1" role="presentation"></a>One option is to make it return a special value. Common choices for such values are <code>null</code>, <code>undefined</code>, or -1.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_ssOc2pf47/" href="#c_ssOc2pf47/" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">promptNumber</span>(<span class="cm-def">question</span>) {

<span class="cm-keyword">let</span> <span class="cm-def">result</span> <span class="cm-operator">=</span> <span class="cm-variable">Number</span>(<span class="cm-variable">prompt</span>(<span class="cm-variable-2">question</span>));

<span class="cm-keyword">if</span> (<span class="cm-variable">Number</span>.<span class="cm-property">isNaN</span>(<span class="cm-variable-2">result</span>)) <span class="cm-keyword">return</span> <span class="cm-atom">null</span>;

<span class="cm-keyword">else</span> <span class="cm-keyword">return</span> <span class="cm-variable-2">result</span>;

}

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-variable">promptNumber</span>(<span class="cm-string">&quot;How many trees do you see?&quot;</span>));</pre>

<p><a class="p_ident" id="p_8/CuHXN0/U" href="#p_8/CuHXN0/U" tabindex="-1" role="presentation"></a>Now any code that calls <code>promptNumber</code> must check whether an actual number was read and, failing that, must somehow recover—maybe by asking again or by filling in a default value. Or it could again return a special value to <em>its</em> caller to indicate that it failed to do what it was asked.</p>

<p><a class="p_ident" id="p_5MsTIzo4xf" href="#p_5MsTIzo4xf" tabindex="-1" role="presentation"></a>In many situations, mostly when errors are common and the caller should be explicitly taking them into account, returning a special value is a good way to indicate an error. It does, however, have its downsides. First, what if the function can already return every possible kind of value? In such a function, you’ll have to do something like wrap the result in an object to be able to distinguish success from failure.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_aQW8dfZcRx" href="#c_aQW8dfZcRx" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">lastElement</span>(<span class="cm-def">array</span>) {

<span class="cm-keyword">if</span> (<span class="cm-variable-2">array</span>.<span class="cm-property">length</span> <span class="cm-operator">==</span> <span class="cm-number">0</span>) {

<span class="cm-keyword">return</span> {<span class="cm-property">failed</span>: <span class="cm-atom">true</span>};

} <span class="cm-keyword">else</span> {

<span class="cm-keyword">return</span> {<span class="cm-property">element</span>: <span class="cm-variable-2">array</span>[<span class="cm-variable-2">array</span>.<span class="cm-property">length</span> <span class="cm-operator">-</span> <span class="cm-number">1</span>]};

}

}</pre>

<p><a class="p_ident" id="p_+E9fllIVBt" href="#p_+E9fllIVBt" tabindex="-1" role="presentation"></a>The second issue with returning special values is that it can lead to awkward code. If a piece of code calls <code>promptNumber</code> 10 times, it has to check 10 times whether <code>null</code> was returned. And if its response to finding <code>null</code> is to simply return <code>null</code> itself, callers of the function will in turn have to check for it, and so on.</p>

<h2><a class="h_ident" id="h_zT3755/aOp" href="#h_zT3755/aOp" tabindex="-1" role="presentation"></a>Exceptions</h2>

<p><a class="p_ident" id="p_ZBsTKhGA4i" href="#p_ZBsTKhGA4i" tabindex="-1" role="presentation"></a>When a function cannot proceed normally, what we would <em>like</em> to do is just stop what we are doing and immediately jump to a place that knows how to handle the problem. This is what <em>exception handling</em> does.</p>

<p><a class="p_ident" id="p_kjXcPy8jGf" href="#p_kjXcPy8jGf" tabindex="-1" role="presentation"></a>Exceptions are a mechanism that makes it possible for code that runs into a problem to <em>raise</em> (or <em>throw</em>) an exception. An exception can be any value. Raising one somewhat resembles a super-charged return from a function: it jumps out of not just the current function but also its callers, all the way down to the first call that started the current execution. This is called <em>unwinding the

stack</em>. You may remember the stack of function calls that was mentioned in <a href="03_functions.html#stack">Chapter 3</a>. An exception zooms down this stack, throwing away all the call contexts it encounters.</p>

<p><a class="p_ident" id="p_giUX2OynLm" href="#p_giUX2OynLm" tabindex="-1" role="presentation"></a>If exceptions always zoomed right down to the bottom of the stack, they would not be of much use. They’d just provide a novel way to blow up your program. Their power lies in the fact that you can set “obstacles” along the stack to <em>catch</em> the exception as it is zooming down. Once you’ve caught an exception, you can do something with it to address the problem and then continue to run the program.</p>

<p><a class="p_ident" id="p_DQmDywMub9" href="#p_DQmDywMub9" tabindex="-1" role="presentation"></a>Here’s an example:</p>

<pre id="look" class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_0VA94HjY2e" href="#c_0VA94HjY2e" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">promptDirection</span>(<span class="cm-def">question</span>) {

<span class="cm-keyword">let</span> <span class="cm-def">result</span> <span class="cm-operator">=</span> <span class="cm-variable">prompt</span>(<span class="cm-variable-2">question</span>);

<span class="cm-keyword">if</span> (<span class="cm-variable-2">result</span>.<span class="cm-property">toLowerCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;left&quot;</span>) <span class="cm-keyword">return</span> <span class="cm-string">&quot;L&quot;</span>;

<span class="cm-keyword">if</span> (<span class="cm-variable-2">result</span>.<span class="cm-property">toLowerCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;right&quot;</span>) <span class="cm-keyword">return</span> <span class="cm-string">&quot;R&quot;</span>;

<span class="cm-keyword">throw</span> <span class="cm-keyword">new</span> <span class="cm-variable">Error</span>(<span class="cm-string">&quot;Invalid direction: &quot;</span> <span class="cm-operator">+</span> <span class="cm-variable-2">result</span>);

}

<span class="cm-keyword">function</span> <span class="cm-def">look</span>() {

<span class="cm-keyword">if</span> (<span class="cm-variable">promptDirection</span>(<span class="cm-string">&quot;Which way?&quot;</span>) <span class="cm-operator">==</span> <span class="cm-string">&quot;L&quot;</span>) {

<span class="cm-keyword">return</span> <span class="cm-string">&quot;a house&quot;</span>;

} <span class="cm-keyword">else</span> {

<span class="cm-keyword">return</span> <span class="cm-string">&quot;two angry bears&quot;</span>;

}

}

<span class="cm-keyword">try</span> {

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-string">&quot;You see&quot;</span>, <span class="cm-variable">look</span>());

} <span class="cm-keyword">catch</span> (<span class="cm-def">error</span>) {

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-string">&quot;Something went wrong: &quot;</span> <span class="cm-operator">+</span> <span class="cm-variable-2">error</span>);

}</pre>

<p><a class="p_ident" id="p_bbpj24fusK" href="#p_bbpj24fusK" tabindex="-1" role="presentation"></a>The <code>throw</code> keyword is used to raise an exception. Catching one is done by wrapping a piece of code in a <code>try</code> block, followed by the keyword <code>catch</code>. When the code in the <code>try</code> block causes an exception to be raised, the <code>catch</code> block is evaluated, with the name in parentheses bound to the exception value. After the <code>catch</code> block finishes—or if the <code>try</code> block finishes without problems—the program proceeds beneath the entire <code>try/catch</code> statement.</p>

<p><a class="p_ident" id="p_lP6PP0CCrB" href="#p_lP6PP0CCrB" tabindex="-1" role="presentation"></a>In this case, we used the <code>Error</code> constructor to create our exception value. This is a standard JavaScript constructor that creates an object with a <code>message</code> property. In most JavaScript environments, instances of this constructor also gather information about the call stack that existed when the exception was created, a so-called <em>stack trace</em>. This information is stored in the <code>stack</code> property and can be helpful when trying to debug a problem: it tells us the function where the problem occurred and which functions made the failing call.</p>

<p><a class="p_ident" id="p_BYCPINQ0h5" href="#p_BYCPINQ0h5" tabindex="-1" role="presentation"></a>Note that the <code>look</code> function completely ignores the possibility that <code>promptDirection</code> might go wrong. This is the big advantage of exceptions: error-handling code is necessary only at the point where the error occurs and at the point where it is handled. The functions in between can forget all about it.</p>

<p><a class="p_ident" id="p_deFX/IC34y" href="#p_deFX/IC34y" tabindex="-1" role="presentation"></a>Well, almost...</p>

<h2><a class="h_ident" id="h_cgoP7o2fe9" href="#h_cgoP7o2fe9" tabindex="-1" role="presentation"></a>Cleaning up after exceptions</h2>

<p><a class="p_ident" id="p_lHGW1D9KYW" href="#p_lHGW1D9KYW" tabindex="-1" role="presentation"></a>The effect of an exception is another kind of control flow. Every action that might cause an exception, which is pretty much every function call and property access, might cause control to suddenly leave your code.</p>

<p><a class="p_ident" id="p_Mqr7VzgCYa" href="#p_Mqr7VzgCYa" tabindex="-1" role="presentation"></a>This means when code has several side effects, even if its “regular” control flow looks like they’ll always all happen, an exception might prevent some of them from taking place.</p>

<p><a class="p_ident" id="p_V7nPGHDnR1" href="#p_V7nPGHDnR1" tabindex="-1" role="presentation"></a>Here is some really bad banking code.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_e3XosnGG47" href="#c_e3XosnGG47" tabindex="-1" role="presentation"></a><span class="cm-keyword">const</span> <span class="cm-def">accounts</span> <span class="cm-operator">=</span> {

<span class="cm-property">a</span>: <span class="cm-number">100</span>,

<span class="cm-property">b</span>: <span class="cm-number">0</span>,

<span class="cm-property">c</span>: <span class="cm-number">20</span>

};

<span class="cm-keyword">function</span> <span class="cm-def">getAccount</span>() {

<span class="cm-keyword">let</span> <span class="cm-def">accountName</span> <span class="cm-operator">=</span> <span class="cm-variable">prompt</span>(<span class="cm-string">&quot;Enter an account name&quot;</span>);

<span class="cm-keyword">if</span> (<span class="cm-operator">!</span><span class="cm-variable">accounts</span>.<span class="cm-property">hasOwnProperty</span>(<span class="cm-variable-2">accountName</span>)) {

<span class="cm-keyword">throw</span> <span class="cm-keyword">new</span> <span class="cm-variable">Error</span>(<span class="cm-string-2">`No such account: ${</span><span class="cm-variable-2">accountName</span><span class="cm-string-2">}</span><span class="cm-string-2">`</span>);

}

<span class="cm-keyword">return</span> <span class="cm-variable-2">accountName</span>;

}

<span class="cm-keyword">function</span> <span class="cm-def">transfer</span>(<span class="cm-def">from</span>, <span class="cm-def">amount</span>) {

<span class="cm-keyword">if</span> (<span class="cm-variable">accounts</span>[<span class="cm-variable-2">from</span>] <span class="cm-operator">&lt;</span> <span class="cm-variable-2">amount</span>) <span class="cm-keyword">return</span>;

<span class="cm-variable">accounts</span>[<span class="cm-variable-2">from</span>] <span class="cm-operator">-=</span> <span class="cm-variable-2">amount</span>;

<span class="cm-variable">accounts</span>[<span class="cm-variable">getAccount</span>()] <span class="cm-operator">+=</span> <span class="cm-variable-2">amount</span>;

}</pre>

<p><a class="p_ident" id="p_lj3bgLcO/p" href="#p_lj3bgLcO/p" tabindex="-1" role="presentation"></a>The <code>transfer</code> function transfers a sum of money from a given account to another, asking for the name of the other account in the process. If given an invalid account name, <code>getAccount</code> throws an exception.</p>

<p><a class="p_ident" id="p_IvzAvOGwRo" href="#p_IvzAvOGwRo" tabindex="-1" role="presentation"></a>But <code>transfer</code> <em>first</em> removes the money from the account and <em>then</em> calls <code>getAccount</code> before it adds it to another account. If it is broken off by an exception at that point, it’ll just make the money disappear.</p>

<p><a class="p_ident" id="p_vSkNwpOGmb" href="#p_vSkNwpOGmb" tabindex="-1" role="presentation"></a>That code could have been written a little more intelligently, for example by calling <code>getAccount</code> before it starts moving money around. But often problems like this occur in more subtle ways. Even functions that don’t look like they will throw an exception might do so in exceptional circumstances or when they contain a programmer mistake.</p>

<p><a class="p_ident" id="p_6ijkWjygkN" href="#p_6ijkWjygkN" tabindex="-1" role="presentation"></a>One way to address this is to use fewer side effects. Again, a programming style that computes new values instead of changing existing data helps. If a piece of code stops running in the middle of creating a new value, no one ever sees the half-finished value, and there is no problem.</p>

<p><a class="p_ident" id="p_lhrnmP99dZ" href="#p_lhrnmP99dZ" tabindex="-1" role="presentation"></a>But that isn’t always practical. So there is another feature that <code>try</code> statements have. They may be followed by a <code>finally</code> block either instead of or in addition to a <code>catch</code> block. A <code>finally</code> block says “no matter <em>what</em> happens, run this code after trying to run the code in the <code>try</code> block.”</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_brWpzDAy4+" href="#c_brWpzDAy4+" tabindex="-1" role="presentation"></a><span class="cm-keyword">function</span> <span class="cm-def">transfer</span>(<span class="cm-def">from</span>, <span class="cm-def">amount</span>) {

<span class="cm-keyword">if</span> (<span class="cm-variable">accounts</span>[<span class="cm-variable-2">from</span>] <span class="cm-operator">&lt;</span> <span class="cm-variable-2">amount</span>) <span class="cm-keyword">return</span>;

<span class="cm-keyword">let</span> <span class="cm-def">progress</span> <span class="cm-operator">=</span> <span class="cm-number">0</span>;

<span class="cm-keyword">try</span> {

<span class="cm-variable">accounts</span>[<span class="cm-variable-2">from</span>] <span class="cm-operator">-=</span> <span class="cm-variable-2">amount</span>;

<span class="cm-variable-2">progress</span> <span class="cm-operator">=</span> <span class="cm-number">1</span>;

<span class="cm-variable">accounts</span>[<span class="cm-variable">getAccount</span>()] <span class="cm-operator">+=</span> <span class="cm-variable-2">amount</span>;

<span class="cm-variable-2">progress</span> <span class="cm-operator">=</span> <span class="cm-number">2</span>;

} <span class="cm-keyword">finally</span> {

<span class="cm-keyword">if</span> (<span class="cm-variable-2">progress</span> <span class="cm-operator">==</span> <span class="cm-number">1</span>) {

<span class="cm-variable">accounts</span>[<span class="cm-variable-2">from</span>] <span class="cm-operator">+=</span> <span class="cm-variable-2">amount</span>;

}

}

}</pre>

<p><a class="p_ident" id="p_LvvK85Vh5F" href="#p_LvvK85Vh5F" tabindex="-1" role="presentation"></a>This version of the function tracks its progress, and if, when leaving, it notices that it was aborted at a point where it had created an inconsistent program state, it repairs the damage it did.</p>

<p><a class="p_ident" id="p_Gs19OQg3TY" href="#p_Gs19OQg3TY" tabindex="-1" role="presentation"></a>Note that even though the <code>finally</code> code is run when an exception is thrown in the <code>try</code> block, it does not interfere with the exception. After the <code>finally</code> block runs, the stack continues unwinding.</p>

<p><a class="p_ident" id="p_yZkXySCQHr" href="#p_yZkXySCQHr" tabindex="-1" role="presentation"></a>Writing programs that operate reliably even when exceptions pop up in unexpected places is hard. Many people simply don’t bother, and because exceptions are typically reserved for exceptional circumstances, the problem may occur so rarely that it is never even noticed. Whether that is a good thing or a really bad thing depends on how much damage the software will do when it fails.</p>

<h2><a class="h_ident" id="h_vfoJqEDazI" href="#h_vfoJqEDazI" tabindex="-1" role="presentation"></a>Selective catching</h2>

<p><a class="p_ident" id="p_HUJ9GRG1jC" href="#p_HUJ9GRG1jC" tabindex="-1" role="presentation"></a>When an exception makes it all the way to the bottom of the stack without being caught, it gets handled by the environment. What this means differs between environments. In browsers, a description of the error typically gets written to the JavaScript console (reachable through the browser’s Tools or Developer menu). Node.js, the browserless JavaScript environment we will discuss in <a href="20_node.html">Chapter 20</a>, is more careful about data corruption. It aborts the whole process when an unhandled exception occurs.</p>

<p><a class="p_ident" id="p_9JOlpepKZE" href="#p_9JOlpepKZE" tabindex="-1" role="presentation"></a>For programmer mistakes, just letting the error go through is often the best you can do. An unhandled exception is a reasonable way to signal a broken program, and the JavaScript console will, on modern browsers, provide you with some information about which function calls were on the stack when the problem occurred.</p>

<p><a class="p_ident" id="p_KGWPPf4CcF" href="#p_KGWPPf4CcF" tabindex="-1" role="presentation"></a>For problems that are <em>expected</em> to happen during routine use, crashing with an unhandled exception is a terrible strategy.</p>

<p><a class="p_ident" id="p_ZkwQ40b3to" href="#p_ZkwQ40b3to" tabindex="-1" role="presentation"></a>Invalid uses of the language, such as referencing a nonexistent binding, looking up a property on <code>null</code>, or calling something that’s not a function, will also result in exceptions being raised. Such exceptions can also be caught.</p>

<p><a class="p_ident" id="p_8IwJJBHBTh" href="#p_8IwJJBHBTh" tabindex="-1" role="presentation"></a>When a <code>catch</code> body is entered, all we know is that <em>something</em> in our <code>try</code> body caused an exception. But we don’t know <em>what</em> did or <em>which</em> exception it caused.</p>

<p><a class="p_ident" id="p_3umLtBJgPo" href="#p_3umLtBJgPo" tabindex="-1" role="presentation"></a>JavaScript (in a rather glaring omission) doesn’t provide direct support for selectively catching exceptions: either you catch them all or you don’t catch any. This makes it tempting to <em>assume</em> that the exception you get is the one you were thinking about when you wrote the <code>catch</code> block.</p>

<p><a class="p_ident" id="p_O9bj9nd33p" href="#p_O9bj9nd33p" tabindex="-1" role="presentation"></a>But it might not be. Some other assumption might be violated, or you might have introduced a bug that is causing an exception. Here is an example that <em>attempts</em> to keep on calling <code>promptDirection</code> until it gets a valid answer:</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_ZxDKrGLCQ3" href="#c_ZxDKrGLCQ3" tabindex="-1" role="presentation"></a><span class="cm-keyword">for</span> (;;) {

<span class="cm-keyword">try</span> {

<span class="cm-keyword">let</span> <span class="cm-def">dir</span> <span class="cm-operator">=</span> <span class="cm-variable">promtDirection</span>(<span class="cm-string">&quot;Where?&quot;</span>); <span class="cm-comment">// ← typo!</span>

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-string">&quot;You chose &quot;</span>, <span class="cm-variable-2">dir</span>);

<span class="cm-keyword">break</span>;

} <span class="cm-keyword">catch</span> (<span class="cm-def">e</span>) {

<span class="cm-variable">console</span>.<span class="cm-property">log</span>(<span class="cm-string">&quot;Not a valid direction. Try again.&quot;</span>);

}

}</pre>

<p><a class="p_ident" id="p_pdL8VKiwnf" href="#p_pdL8VKiwnf" tabindex="-1" role="presentation"></a>The <code>for (;;)</code> construct is a way to intentionally create a loop that doesn’t terminate on its own. We break out of the loop only when a valid direction is given. <em>But</em> we misspelled <code>promptDirection</code>, which will result in an “undefined variable” error. Because the <code>catch</code> block completely ignores its exception value (<code>e</code>), assuming it knows what the problem is, it wrongly treats the binding error as indicating bad input. Not only does this cause an infinite loop, it “buries” the useful error message about the misspelled binding.</p>

<p><a class="p_ident" id="p_hk/lwBIhah" href="#p_hk/lwBIhah" tabindex="-1" role="presentation"></a>As a general rule, don’t blanket-catch exceptions unless it is for the purpose of “routing” them somewhere—for example, over the network to tell another system that our program crashed. And even then, think carefully about how you might be hiding information.</p>

<p><a class="p_ident" id="p_o1E5pkUD5g" href="#p_o1E5pkUD5g" tabindex="-1" role="presentation"></a>So we want to catch a <em>specific</em> kind of exception. We can do this by checking in the <code>catch</code> block whether the exception we got is the one we are interested in and rethrowing it otherwise. But how do we recognize an exception?</p>

<p><a class="p_ident" id="p_qurSIk3pjE" href="#p_qurSIk3pjE" tabindex="-1" role="presentation"></a>We could compare its <code>message</code> property against the error message we happen to expect. But that’s a shaky way to write code—we’d be using information that’s intended for human consumption (the message) to make a programmatic decision. As soon as someone changes (or translates) the message, the code will stop working.</p>

<p><a class="p_ident" id="p_Pml4dAzuT1" href="#p_Pml4dAzuT1" tabindex="-1" role="presentation"></a>Rather, let’s define a new type of error and use <code>instanceof</code> to identify it.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_miFD8lvrWj" href="#c_miFD8lvrWj" tabindex="-1" role="presentation"></a><span class="cm-keyword">class</span> <span class="cm-def">InputError</span> <span class="cm-keyword">extends</span> <span class="cm-variable">Error</span> {}

<span class="cm-keyword">function</span> <span class="cm-def">promptDirection</span>(<span class="cm-def">question</span>) {

<span class="cm-keyword">let</span> <span class="cm-def">result</span> <span class="cm-operator">=</span> <span class="cm-variable">prompt</span>(<span class="cm-variable-2">question</span>);

<span class="cm-keyword">if</span> (<span class="cm-variable-2">result</span>.<span class="cm-property">toLowerCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;left&quot;</span>) <span class="cm-keyword">return</span> <span class="cm-string">&quot;L&quot;</span>;

<span class="cm-keyword">if</span> (<span class="cm-variable-2">result</span>.<span class="cm-property">toLowerCase</span>() <span class="cm-operator">==</span> <span class="cm-string">&quot;right&quot;</span>) <span class="cm-keyword">return</span> <span class="cm-string">&quot;R&quot;</span>;

<span class="cm-keyword">throw</span> <span class="cm-keyword">new</span> <span class="cm-variable">InputError</span>(<span class="cm-string">&quot;Invalid direction: &quot;</span> <span class="cm-operator">+</span> <span class="cm-variable-2">result</span>);

}</pre>

<p><a class="p_ident" id="p_/YM4ZmoOGt" href="#p_/YM4ZmoOGt" tabindex="-1" role="presentation"></a>The new error class extends <code>Error</code>. It doesn’t define its own constructor, which means that it inherits the <code>Error</code> constructor, which expects a string message as argument. In fact, it doesn’t define anything at all—the class is empty. <code>InputError</code> objects behave like <code>Error</code> objects, except that they have a different class by which we can recognize them.</p>

<p><a class="p_ident" id="p_JqyLwQxCGY" href="#p_JqyLwQxCGY" tabindex="-1" role="presentation"></a>Now the loop can catch these more carefully.</p>

<pre class="snippet cm-s-default" data-language="javascript" ><a class="c_ident" id="c_ab/mR1C1nr" href="#c_ab/mR1C1nr" tabindex="-1" role="presentation"></a><span class="cm-keyword">for</span> (;;) {