:chap_num: 8

:prev_link: 07_elife

:next_link: 09_regexp

:load_files: ["code/chapter/08_error.js"]

= Bugs and Error Handling =

[chapterquote="true"]

[quote, Brian Kernighan and P.J. Plauger, The Elements of Programming Style]

____

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.

____

ifdef::interactive_target[]

[chapterquote="true"]

[quote, Master Yuan-Ma, The Book of Programming]

____

Yuan-Ma had written a small program that used many global variables

and shoddy shortcuts. Reading it, a student asked, ‘You warned us

against these techniques, yet I find them in your program. How can

this be?’ The master said, ‘There is no need to fetch a water hose

when the house is not on fire.’

____

endif::interactive_target[]

(((Kernighan+++,+++ Brian)))(((Plaugher+++,+++ P.J.)))(((debugging)))(((error handling)))A program is crystallized thought.

Sometimes those thoughts are confused. Other times, mistakes are

introduced when converting thought into code. Either way, the result

is a flawed program.

(((input)))(((output)))Flaws in a program are usually called ((bug))s.

Bugs can be programmer errors or problems in other systems that the

program interacts with. Some bugs are immediately apparent, while

others are subtle and might remain hidden in a system for years.

Often, problems surface only when a program encounters a situation

that the programmer didn't originally consider. Sometimes such

situations are unavoidable. When the user is asked to input their age

and types _orange_, this puts our program in a difficult position. The

situation has to be anticipated and handled somehow.

== Programmer mistakes ==

(((parsing)))(((analysis)))When it comes to programmer mistakes, our

aim is simple. We want to find them and fix them. Such mistakes can

range from simple ((typo))s that cause the computer to complain as

soon as it lays eyes on our program to subtle mistakes in our

understanding of the way the program operates, causing incorrect

outcomes only in specific situations. Bugs of the latter type can

take weeks to diagnose.

(((programming language)))(((type)))(((static typing)))(((dynamic

typing)))(((run-time error)))(((error)))The degree to which languages

help you find such mistakes varies. Unsurprisingly, JavaScript is at

the “hardly helps at all” end of that scale. Some languages want to

know the types of all your variables and expressions before even

running a program and 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 then, it allows you to do some clearly

nonsensical things without complaint, such as `x = true * "monkey"`.

(((syntax)))There are some things that JavaScript does complain about,

though. Writing a program that is not syntactically valid will

immediately trigger an error. 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 is running

and encounters the nonsensical action.

(((NaN)))(((error)))But often, your nonsense computation will simply

produce a `NaN` (not a number) or undefined value. And the program

happily continues, convinced that it's doing something meaningful. The

mistake will manifest itself only later, after the bogus value has

traveled though 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.

(((debugging)))The process of finding mistakes—bugs—in programs is

called _debugging_.

== Strict mode ==

indexsee:[use strict,strict mode]

(((strict mode)))(((syntax)))(((function)))JavaScript can be made a

_little_ more strict by enabling _strict mode_. This is done by

putting the string `"use strict"` at the top of a file or a function

body. Here's an example:

// test: error "ReferenceError: counter is not defined"

[source,javascript]

----

function canYouSpotTheProblem() {

"use strict";

for (counter = 0; counter < 10; counter++)

console.log("Happy happy");

}

canYouSpotTheProblem();

// → ReferenceError: counter is not defined

----

(((var keyword)))(((variable,global)))Normally, when you forget to put

`var` in front of your variable, as with `counter` in the example,

JavaScript quietly creates a global variable and uses that. In strict

mode, however, an ((error)) is reported instead. This is very helpful.

It should be noted, though, that this doesn't work when the variable

in question already exists as a global variable, but only when

assigning to it would have created it.

(((this)))(((global object)))(((undefined)))(((strict mode)))Another

change in strict mode is that the `this` binding holds the value

`undefined` in functions that are not called as ((method))s. When

making such a call outside of strict mode, `this` refers to the global

scope object. 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 `this`, rather than happily working

with the global object, creating and reading global variables.

For example, consider the following code, which calls a

((constructor)) without the `new` keyword so that its `this` will

_not_ refer to a newly constructed object:

[source,javascript]

----

function Person(name) { this.name = name; }

var ferdinand = Person("Ferdinand"); // oops

console.log(name);

// → Ferdinand

----

(((error)))So the bogus call to `Person` succeeded but returned an

undefined value and created the global variable `name`. In strict

mode, the result is different.

// test: error "TypeError: Cannot set property 'name' of undefined"

[source,javascript]

----

"use strict";

function Person(name) { this.name = name; }

// Oops, forgot 'new'

var ferdinand = Person("Ferdinand");

// → TypeError: Cannot set property 'name' of undefined

----

We are immediately told that something is wrong. This is helpful.

(((parameter)))(((variable,naming)))(((with statement)))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 `with` statement, which is so

misguided it is not further discussed in this book).

(((debugging)))In short, putting a `"use strict"` at the top of your

program rarely hurts and might help you spot a problem.

== Testing ==

(((test suite)))(((run-time error)))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.

Doing this by hand, again and again, is a sure way to drive yourself

insane. Fortunately, it is often possible to write a second program

that automates testing your actual program.

(((Vector type)))As an example, we once again use the `Vector` type.

// include_code

[source,javascript]

----

function Vector(x, y) {

this.x = x;

this.y = y;

}

Vector.prototype.plus = function(other) {

return new Vector(this.x + other.x, this.y + other.y);

};

----

We will write a program to check that our implementation of `Vector`

works as intended. Then, every time we change the implementation, we

follow up by running the test program so that we can be reasonably

confident that we didn't break anything. When we add extra

functionality (for example, a new method) to the `Vector` type, we also

add tests for the new feature.

[source,javascript]

----

function testVector() {

var p1 = new Vector(10, 20);

var p2 = new Vector(-10, 5);

var p3 = p1.plus(p2);

if (p1.x !== 10) return "fail: x property";

if (p1.y !== 20) return "fail: y property";

if (p2.x !== -10) return "fail: negative x property";

if (p3.x !== 0) return "fail: x from plus";

if (p3.y !== 25) return "fail: y from plus";

return "everything ok";

}

console.log(testVector());

// → everything ok

----

(((test suite)))(((testing framework)))(((domain-specific

language)))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 (_test suites_) 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 called _testing frameworks_.

== Debugging ==

(((debugging)))Once you notice that there is something wrong with your

program because it misbehaves or produces errors, the next step is to

figure out _what_ the problem is.

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.

(((run-time error)))But not always. Sometimes the line that triggered

the problem is simply the first place where a bogus value produced

elsewhere gets used in an invalid way. And sometimes there is no error

message at all—just an invalid result. If you have been solving the

((exercises)) in the earlier chapters, you will probably have already

experienced such situations.

(((decimal number)))(((binary number)))The following example program

tries to convert a whole number to a string in any 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 insane output

that it currently produces suggests that it has a ((bug)).

[source,javascript]

----

function numberToString(n, base) {

var result = "", sign = "";

if (n < 0) {

sign = "-";

n = -n;

}

do {

result = String(n % base) + result;

n /= base;

} while (n > 0);

return sign + result;

}

console.log(numberToString(13, 10));

// → 1.5e-3231.3e-3221.3e-3211.3e-3201.3e-3191.3e-3181.3…

----

(((analysis)))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.

(((trial and error)))This is where you must resist the urge to start

making random changes to the code. Instead, _think_. 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 that might help

you come up with one.

(((console.log)))(((output)))(((debugging)))(((logging)))Putting a few

strategic `console.log` calls into the program is a good way to get

additional information about what the program is doing. In this case,

we want `n` to take the values `13`, `1`, and then `0`. Let's write

out its value at the start of the loop.

----

13

1.3

0.13

0.013

…

1.5e-323

----

(((rounding)))_Right_. Dividing 13 by 10 does not produce a whole

number. Instead of `n /= base`, what we actually want is `n =

Math.floor(n / base)` so that the number is properly “shifted” to the

right.

(((JavaScript console)))(((breakpoint)))(((debugger statement)))An

alternative to using `console.log` is to use the _debugger_

capabilities of your browser. Modern browsers come with the ability to

set a _breakpoint_ on a specific line of your code. This will cause

the execution of the program to pause every time the line with the

breakpoint is reached and allow you to inspect the values of

variables at that point. I won't go into details here since debuggers

differ from browser to browser, but look in your browser's developer

tools and search the Web for more information. Another way to set a

breakpoint is to include a `debugger` 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 that

statement, and you will be able to inspect its state.

== Error propagation ==

(((input)))(((output)))(((run-time

error)))(((error)))(((validation)))Not all problems can be prevented

by the programmer, unfortunately. If your program communicates with

the outside world in any way, there is a chance that the input it gets

will be invalid or that other systems that it tries to talk to are

broken or unreachable.

(((error recovery)))Simple programs, or programs that run only under

your supervision, can afford to just give up when such a problem

occurs. You'll look into the problem and try again. “Real”

applications, on the other hand, are expected to not simply 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.

(((promptInteger function)))(((validation)))Say you have a function

`promptInteger` that asks the user for a whole number and returns it.

What should it return if the user inputs _orange_?

(((null)))(((undefined)))(((return value)))(((special return

value)))One option is to make it return a special value. Common

choices for such values are `null` and `undefined`.

// test: no

[source,javascript]

----

function promptNumber(question) {

var result = Number(prompt(question, ""));

if (isNaN(result)) return null;

else return result;

}

console.log(promptNumber("How many trees do you see?"));

----

This is a sound strategy. Now any code that calls `promptNumber` 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 _its_ caller to

indicate that it failed to do what it was asked.

(((error handling)))In many situations, mostly when ((error))s are

common and the caller should be explicitly taking them into account,

returning a special value is a perfectly fine way to indicate an

error. It does, however, have its downsides. First, what if the

function can already return every possible kind of value? For such a

function, it is hard to find a special value that can be distinguished

from a valid result.

(((special return value)))(((readability)))The second issue with

returning special values is that it can lead to some very cluttered

code. If a piece of code calls `promptNumber` 10 times, it has to

check 10 times whether `null` was returned. And if its response to

finding `null` is to simply return `null` itself, the caller will in

turn have to check for it, and so on.

== Exceptions ==

(((error handling)))When a function cannot proceed normally, what we

would _like_ to do is just stop what we are doing and immediately jump

back to a place that knows how to handle the problem. This is what

_((exception handling))_ does.

(((control flow)))(((raising (exception))))(((throw keyword)))(((call

stack)))Exceptions are a mechanism that make it possible for code that

runs into a problem to _raise_ (or _throw_) an exception, which is

simply a value. Raising an exception somewhat resembles a

super-charged return from a function: it jumps out of not just the

current function but also out of its callers, all the way down to the

first call that started the current execution. This is called

_((unwinding the stack))_. You may remember the stack of function

calls that was mentioned in link:03_functions.html#stack[Chapter 3].

An exception zooms down this stack, throwing away all the call

contexts it encounters.

(((error handling)))(((syntax)))(((catch keyword)))If exceptions

always zoomed right down to the bottom of the stack, they would not be

of much use. They would 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 _catch_ the exception as it is zooming down. Then

you can do something with it, after which the program continues

running at the point where the exception was caught.

Here's an example:

[[look]]

[source,javascript]

----

function promptDirection(question) {

var result = prompt(question, "");

if (result.toLowerCase() == "left") return "L";

if (result.toLowerCase() == "right") return "R";

throw new Error("Invalid direction: " + result);

}

function look() {

if (promptDirection("Which way?") == "L")

return "a house";

else

return "two angry bears";

}

try {

console.log("You see", look());

} catch (error) {

console.log("Something went wrong: " + error);

}

----

(((exception handling)))(((block)))(((throw keyword)))(((try

keyword)))(((catch keyword)))The `throw` keyword is used to raise an

exception. Catching one is done by wrapping a piece of code in a `try`

block, followed by the keyword `catch`. When the code in the `try`

block causes an exception to be raised, the `catch` block is

evaluated. The variable name (in parentheses) after `catch` will be

bound to the exception value. After the `catch` block finishes—or if

the `try` block finishes without problems—control proceeds beneath the

entire `try/catch` statement.

(((debugging)))(((call stack)))(((Error type)))(((stack

trace)))In this case, we used the `Error` ((constructor)) to create

our exception value. This is a ((standard)) JavaScript constructor

that creates an object with a `message` property. In modern JavaScript

environments, instances of this constructor also gather information

about the call stack that existed when the exception was created, a

so-called _stack trace_. This information is stored in the `stack`

property and can be helpful when trying to debug a problem: it

tells us the precise function where the problem occurred and which

other functions led up to the call that failed.

(((exception handling)))Note that the function `look` completely

ignores the possibility that `promptDirection` 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.

Well, almost...

== Cleaning up after exceptions ==

(((exception handling)))(((cleaning up)))(((withContext

function)))(((dynamic scope)))Consider the following situation: a

function, `withContext`, wants to make sure that, during its

execution, the top-level variable `context` holds a specific context

value. After it finishes, it restores this variable to its old value.

// include_code

[source,javascript]

----

var context = null;

function withContext(newContext, body) {

var oldContext = context;

context = newContext;

var result = body();

context = oldContext;

return result;

}

----

What if `body` raises an exception? In that case, the call to

`withContext` will be thrown off the stack by the exception, and

`context` will never be set back to its old value.

(((block)))(((try keyword)))(((finally keyword)))There is one more

feature that `try` statements have. They may be followed by a

`finally` block either instead of or in addition to a `catch`

block. A `finally` block means “No matter _what_ happens, run this

code after trying to run the code in the `try` block”. If a function

has to clean something up, the cleanup code should usually be put into

a `finally` block.

// include_code

[source,javascript]

----

function withContext(newContext, body) {

var oldContext = context;

context = newContext;

try {

return body();

} finally {

context = oldContext;

}

}

----

(((withContext function)))Note that we no longer have to store the

result of `body` (which we want to return) in a variable. Even if we

return directly from the `try` block, the `finally` block will be run.

Now we can do this and be safe:

// test: no

[source,javascript]

----

try {

withContext(5, function() {

if (context < 10)

throw new Error("Not enough context!");

});

} catch (e) {

console.log("Ignoring: " + e);

}

// → Ignoring: Error: Not enough context!

console.log(context);

// → null

----

Even though the function called from `withContext` exploded,

`withContext` itself still properly cleaned up the `context` variable.

== Selective catching ==

(((uncaught exception)))(((exception handling)))(((JavaScript

console)))(((developer tools)))(((call stack)))(((error)))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).

(((crash)))(((error handling)))For programmer mistakes or problems

that the program cannot possibly handle, just letting the error go

through is often okay. 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.

(((user interface)))For problems that are _expected_ to happen during

routine use, crashing with an unhandled exception is not a very

friendly response.

(((syntax)))(((function,application)))(((exception handling)))(((Error

type)))Invalid uses of the language, such as referencing a nonexistent

((variable)), looking up a property on `null`, or calling something

that's not a function, will also result in exceptions being raised.

Such exceptions can be caught just like your own exceptions.

(((catch keyword)))When a `catch` body is entered, all we know is that

_something_ in our `try` body caused an exception. But we don't know

_what_, or _which_ exception it caused.

(((exception handling)))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 very

easy to _assume_ that the exception you get is the one you were

thinking about when you wrote the `catch` block.

(((promptDirection function)))But it might not be. Some other

((assumption)) might be violated, or you might have introduced a bug

somewhere that is causing an exception. Here is an example, which

_attempts_ to keep on calling `promptDirection` until it gets a valid

answer:

// test: no

[source,javascript]

----

for (;;) {

try {

var dir = promtDirection("Where?"); // ← typo!

console.log("You chose ", dir);

break;

} catch (e) {

console.log("Not a valid direction. Try again.");

}

}

----

(((infinite loop)))(((for loop)))(((catch keyword)))(((debugging)))The

`for (;;)` 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. _But_ we misspelled `promptDirection`,

which will result in an “undefined variable” error. Because the

`catch` block completely ignores its exception value (`e`), assuming

it knows what the problem is, it wrongly treats the variable error as

indicating bad input. Not only does this cause an infinite loop, but

it also “buries” the useful error message about the misspelled

variable.

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.

(((exception handling)))So we want to catch a _specific_ kind of

exception. We can do this by checking in the `catch` block whether the

exception we got is the one we are interested in and by rethrowing it

otherwise. But how do we recognize an exception?

Of course, we could match its `message` 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.

(((Error type)))(((instanceof operator)))Rather, let's define a new

type of error and use `instanceof` to identify it.

// include_code

[source,javascript]

----

function InputError(message) {

this.message = message;

this.stack = (new Error()).stack;

}

InputError.prototype = Object.create(Error.prototype);

InputError.prototype.name = "InputError";

----

(((throw keyword)))(((inheritance)))The prototype is made to derive

from `Error.prototype` so that `instanceof Error` will also return

true for `InputError` objects. It's also given a `name` property

since the standard error types (`Error`, `SyntaxError`,

`ReferenceError`, and so on) also have such a property.

(((call stack)))The assignment to the `stack` property tries to give

this object a somewhat useful ((stack trace)), on platforms that

support it, by creating a regular error object and then using that

object's `stack` property as its own.

(((promptDirection function)))Now `promptDirection` can throw such an

error.

// include_code

[source,javascript]

----

function promptDirection(question) {

var result = prompt(question, "");

if (result.toLowerCase() == "left") return "L";

if (result.toLowerCase() == "right") return "R";

throw new InputError("Invalid direction: " + result);

}

----

(((exception handling)))And the loop can catch it more carefully.

// test: no

[source,javascript]

----

for (;;) {

try {

var dir = promptDirection("Where?");

console.log("You chose ", dir);

break;

} catch (e) {

if (e instanceof InputError)

console.log("Not a valid direction. Try again.");

else

throw e;

}

}

----

(((debugging)))This will catch only instances of `InputError` and let

unrelated exceptions through. If you reintroduce the typo, the

undefined variable error will be properly reported.

== Assertions ==

(((assert function)))(((assertion)))(((debugging)))_Assertions_ are a

tool to do basic sanity checking for programmer errors. Consider this

helper function, `assert`:

[source,javascript]

----

function AssertionFailed(message) {

this.message = message;

}

AssertionFailed.prototype = Object.create(Error.prototype);

function assert(test, message) {

if (!test)

throw new AssertionFailed(message);

}

function lastElement(array) {

assert(array.length > 0, "empty array in lastElement");

return array[array.length - 1];

}

----

(((validation)))(((run-time

error)))(((crash)))(((assumption)))(((array)))This provides a

compact way to enforce expectations, helpfully blowing up the program

if the stated condition does not hold. For instance, the `lastElement`

function, which fetches the last element from an array, would return

`undefined` on empty arrays if the assertion was omitted. Fetching the

last element from an empty array does not make much sense, so it is

almost certainly a programmer error to do so.

(((assertion)))(((debugging)))Assertions are a way to make sure

mistakes cause failures at the point of the mistake, rather than

silently producing nonsense values that may go on to cause trouble in

an unrelated part of the system.

== Summary ==

Mistakes and bad input are facts of life. Bugs in programs need to be

found and fixed. They can become easier to notice by having automated

test suites and adding assertions to your programs.

Problems caused by factors outside the program's control should

usually be handled gracefully. Sometimes, when the problem can be

handled locally, special return values are a sane way to track them.

Otherwise, exceptions are preferable.

Throwing an exception causes the call stack to be unwound until the

next enclosing `try/catch` block or until the bottom of the stack.

The exception value will be given to the `catch` block that catches

it, which should verify that it is actually the expected kind of

exception and then do something with it. To deal with the

unpredictable control flow caused by exceptions, `finally` blocks can

be used to ensure a piece of code is _always_ run when a block

finishes.

== Exercises ==

=== Retry ===

(((primitiveMultiply (exercise))))(((exception handling)))(((throw

keyword)))Say you have a function `primitiveMultiply` that, in 50 percent of

cases, multiplies two numbers, and in the other 50 percent, raises an

exception of type `MultiplicatorUnitFailure`. Write a function that

wraps this clunky function and just keeps trying until a call

succeeds, after which it returns the result.

(((catch keyword)))Make sure you handle only the exceptions you

are trying to handle.

ifdef::interactive_target[]

// test: no

[source,javascript]

----

function MultiplicatorUnitFailure() {}

function primitiveMultiply(a, b) {

if (Math.random() < 0.5)

return a * b;

else

throw new MultiplicatorUnitFailure();

}

function reliableMultiply(a, b) {

// Your code here.

}

console.log(reliableMultiply(8, 8));

// → 64

----

endif::interactive_target[]

!!hint!!

(((primitiveMultiply (exercise))))(((try keyword)))(((catch

keyword)))(((throw keyword)))The call to `primitiveMultiply` should

obviously happen in a `try` block. The corresponding `catch` block

should rethrow the exception when it is not an instance of

`MultiplicatorUnitFailure` and ensure the call is retried when it is.

To do the retrying, you can either use a loop that breaks only when a

call succeeds—as in the link:08_error.html#look[`look` example]

earlier in this chapter—or use ((recursion)) and hope you don't get a

string of failures so long that it overflows the stack (which is a

pretty safe bet).

!!hint!!

=== The locked box ===

(((locked box (exercise))))Consider the following (rather contrived)

object:

// include_code

[source,javascript]

----

var box = {

locked: true,

unlock: function() { this.locked = false; },

lock: function() { this.locked = true; },

_content: [],

get content() {

if (this.locked) throw new Error("Locked!");

return this._content;

}

};

----

(((private property)))(((access control)))It is a ((box)) with a

lock. Inside is an array, but you can get at it only when the box is

unlocked. Directly accessing the `_content` property is not allowed.

(((finally keyword)))(((exception handling)))Write a function called

`withBoxUnlocked` that takes a function value as argument, unlocks the

box, runs the function, and then ensures that the box is locked again

before returning, regardless of whether the argument function returned

normally or threw an exception.

ifdef::interactive_target[]

[source,javascript]

----

function withBoxUnlocked(body) {

// Your code here.

}

withBoxUnlocked(function() {

box.content.push("gold piece");

});

try {

withBoxUnlocked(function() {

throw new Error("Pirates on the horizon! Abort!");

});

} catch (e) {

console.log("Error raised:", e);

}

console.log(box.locked);

// → true

----

For extra points, make sure that if you call `withBoxUnlocked` when

the box is already unlocked, the box stays unlocked.

endif::interactive_target[]

!!hint!!

(((locked box (exercise))))(((finally keyword)))(((try keyword)))This

exercise calls for a `finally` block, as you probably guessed. Your

function should first unlock the box and then call the argument function

from inside a `try` body. The `finally` block after it should lock the

box again.

To make sure we don't lock the box when it wasn't already locked,

check its lock at the start of the function and unlock and lock

it only when it started out locked.

!!hint!!