 In describing JavaScript in Pigeon, I've occasionally mentioned how some code will trigger errors. JavaScript calls these errors exceptions. For example, using an operator on the wrong kind of operands triggers an exception. Here, multiplying a string by a boolean triggers an exception because the multiplication operator doesn't accept those types as valid operands. Normally, when an exception occurs, the program will terminate. However, exceptions triggered in a try block will be caught, allowing the program to continue executing despite the error. Here, the same multiplication of a string and boolean is in a try block, so when the exception triggers, execution skips over the rest of the try, jumping immediately to the try accompanying catch clause. The catch clause includes a single variable name in parentheses, which acts something like a function parameter. We're free to name this variable whatever we want, but I always like to call it x, short for exception. This variable is local to the catch clause, so it disappears once execution leaves the catch block. The value passed to this variable is what's called the exception object, an object with information about the exception which is generated when the exception is triggered. In the code of the catch clause, we may choose to use this exception object, or we may simply ignore it. Again, what happens here is that the multiplication operation triggers an exception, an exception object describing the error is generated, and execution jumps to the catch block where the exception object passed to its parameter. Now, the idea behind all of this is that the programmer may be able to handle, as we say, some kinds of errors. Be clear, though, that for some kinds of errors, the program really can't do anything better in their eventuality other than simply terminate. In this artificial example, the real proper thing to do is not catch this erroneous use of the multiplication operator, but rather just fix the bad code. In other cases, however, the programmer might be able to cope with the eventuality of some kinds of errors. The classic example is what might happen when the program opens a file. If a program is reading a file from a USB thumb drive, one thing beyond the program's control is whether the user might yank out the thumb drive at any moment. What the program can do, however, is catch the exception triggered when this happens, and then do something like display an alert message telling the dummy user to plug the drive back in. So, there's a reason we call them exceptions. Exceptions are the uncommon eventualities, the exceptional circumstances, which our program should account for to the best of its abilities. As already explained, erroneous uses of language features, like the built-in operators, trigger exceptions. It's also possible, though, to deliberately trigger your own custom exceptions. At certain points in your own code, your logic may be able to detect some circumstances that prevent the code from proceeding as normal. For example, a function may determine that the argument values passed to it are no good, such that the function cannot complete its normal task. In such a case, it makes sense to deliberately trigger an exception. This is done in JavaScript with a throw statement, the reserved word throw followed by the object describing the exception, the so-called exception object. Most simply, the exception object can be just a string. Here, the throw statement triggers an exception with a string as its object, and execution jumps to the catch block, passing the string to the parameter x. Again, the code in the catch may simply ignore the exception object if we so choose. The last big thing to understand about exceptions is that an exception not caught by a try block will propagate up the chain of function calls. What this means is that if we have some function in which an exception is triggered but not caught, execution will jump out of the function, and the exception will propagate to where the function was called, such that the exception must be caught there, lest it propagate again. This will happen ad infinitum until the exception propagates to the top level of code, and if not caught there, the exception will terminate the program. So here, for example, if an exception is triggered and not caught in the call to foo, execution of foo will end early, and the exception will propagate to where foo was called. Because the call to foo is in a try block, the exception is caught, and execution jumps to the catch block. Here, however, where ak calls bar, and bar calls foo, when an exception in the call to foo is not caught, the exception propagates to where foo was called, and because the exception isn't caught there, it propagates to where bar was called, and because the exception isn't caught there, it propagates to where ak was called, and finally because the exception isn't caught there either at the top level of code, the exception terminates the program. So that covers the mechanics of exceptions. However, understanding when exactly you should trigger and handle exceptions is a trickier subject, part of what we broadly call error handling. Honestly though, you can avoid doing much error handling until you start writing programs of significant length. It may actually be a good while before you deal much with exceptions in your code.