Getting Good with JavaScript - Andrew Burgess [24]
Another place where this is useful is in creating modules. Check this out:
var a_module = (function () {
var private_variable = "some value";
function private_function () {
// some code;
}
return {
public_property : "something"
// etc : " ... "
};
}());
This is the module pattern: inside a anonymous self-invoking function, we create variable and methods that we don't have available from the outside. Then, we return an object with public properties and methods that use these private variable and methods. This way, the "guts" that shouldn't be exposed aren't. If you want to read more about the module pattern, check out this post of the YUI Blog.
You probably understand the "how" of closure. Maybe you're still struggling with the "why." After all, it's your code and you know enough not to hurt anything, or change something that shouldn't be changed. Well, building in protection like this is one of the best practices of good coding. It's defensive; coding this way means you're aware of the things that can go wrong and are actively preventing them. Also, there's a good chance your code will eventually be used by others; they won't know necessarily how things are "supposed" to work, and coding this way will prevent rampant breakage in such situations.
For example, look back up at the revealSecret function about. We might know not to change the secretNumber variable, but another developer might not … or we might forget. Basically, any situation where you want to be able to change a value over multiple executions of a function (meaning you can't put the value inside the function), but not have that value changeable from outside the function (meaning you can't put the value outside the function) is a situation where closure comes to your rescue.
It's not just other programmers that you have to prepare for. Nine times out of ten, your programs will interact with data from the user. But who is to say that the user will docilely do as they are told and input the right type of information. Defensive coding sometimes means having a backup plan for situations like these.
Errors
This brings us to errors in your JavaScript. Now, there are really two types of errors: errors you make while coding—things like syntax errors and typos—and errors that are unforeseeable—things are break because of something outside your code, such as the user's input, or a missing feature in the JavaScript engine. While the JavaScript engines usually silently solves small errors (such as a missing semicolon), a larger mistake will make it throw (yes, that's the technical term—throw) an error. Also, we can throw our own errors, if something goes wrong.
Here's the error-protection syntax:
try {
// code that might cause an error here
} catch (e) {
// deal with the error here
}
We wrap the code that might throw an error in a try block. If we don't do this, the JavaScript engine will deal with the error itself, which usually means stopping the execution of your code and potentially showing the user the error: not good. If an error is thrown, the error object (which we'll look at soon) is passed to the catch block (you can call it whatever you want; in this case, I'm calling it e, which is common). Inside the catch block, you can deal with the error.
Different web browsers include different properties on the error object. They all include the error name and the error message. Firefox also includes the file name and line number of the error. Chrome includes a stack trace. There are other things, but the main ones are name and message, which are the type of error and a description of what happened, respectively. You can throw your own errors using the throw keyword and creating an error object. You can create this error object as an object literal, or you can use the