JavaScript: Checking for undeclared and undefined variables

Up until now, the JavaScript I've written has typically been in pursuit of a bigger goal. This means that I worked around language quirks on the spot and moved on. I never stopped to consider the nitty gritty details of the language for commitment to long-term memory, because I wanted to get a working end product.

Recently, someone asked me about the best way to check for undefined JavaScript variables. I found myself at a loss, which was alarming to me since doing these kinds of checks is immensely important, practical, and a frequent fact of everyday programming no matter what programming language you're using.

The fact of the matter is that most of the time, I know where my variables are coming from. Something like this would work:

    var x;

    if (x)
        x.some_method();
    else
        alert("we can't use x");

In the vast majority of cases where I had to perform a null check, I knew that the variable was declared somewhere because it was of my own making.

What if you're counting on something having been declared somewhere else and being there? Let's try this.

    if (y)
        y.some_method();
    else
        alert("we can't use y");

In this case, you should get a ReferenceError thrown. You'll see this if you're using the Firebug JavaScript console or the developer tools in Safari or Chrome.

After much experimenting and looking around the web, here's my definitive, reliable, robust, cross-browser way to perform this kind of check:

    if (typeof(z) != "undefined")
        z.some_method();
    else
        alert("we can't use z");

It also works for when you're the one in charge of declaring a variable, too.

    var w;

    if (typeof(w) != "undefined")
        w.some_method();
    else
        alert("we can't use w");

So that fixes our problem. But look closer, and you may have a couple of nagging questions.

Why in the world would you be referencing a variable you didn't declare? If we only ever had to deal our own code, we should always know where the variables that we're using are coming from. But that is not the case for many of us; we rely on using others' code, third-party modules, or frameworks all the time.

An easy example is if you want to send debugging output to console.log in Firebug. When Firebug is disabled, console isn't a declared JavaScript object. (Safari and Chrome have their developer tools more integrated so this problem doesn't appear.) It helps to first check if there's a debugging console available before you start writing to it.

You could also find yourself in a situation where you're expecting some object to be initialized because it's an external library. If it's loaded over the network, and loaded separately from the rest of your code, you'll want to recover gracefully if it's not available for some reason (like the remote server is down).

Why do we have to compare to the string "undefined" instead of the keyword? Because typeof() always returns a string.

    console.log(typeof(j));             // "undefined"
    console.log(typeof(typeof(j)));     // "string"

This seems too simple/short. Will it work in all web browsers? This will work in any modern web browser that supports JavaScript. Just to be thorough, I've personally verified that it works as expected in Internet Explorer 8, Firefox 3.6, Safari 4, and Google Chrome 5.0.

Checking for undefined variables in JavaScript in this way has been around for a long time, and several other sources suggest this method. I wrote this up mainly as an extended explanation for why things are the way they are, and to explicitly address quirks like typeof() always returning a string.

What if it could also be null in some cases? Then you add a check for null. I've limited the check to checking for "undefined" to keep the explanation focused, but yes, in reality you'll want to do an additional check.

    var k;

    if (typeof(k) != "undefined" && k)
        k.some_method();
    else
        alert("we can't use k");

The check for null is pretty straightforward; it's "undefined" that trips us up. Note that, as written, this code will only proceed to check for the null condition if k has been defined. This is because of short-circuiting: if the first condition is true, there's no need to evaluate the rest of the other parts of the conditions.

When it comes down to it, the key insight is that JavaScript has "undefined" variables in two senses: first, when they're not even declared, and second, when a variable has been declared but hasn't been assigned a value. This is when it really is undefined in the strict sense.

We also saw that typeof() will always return a string, which means you need to compare its result to a string when you're running a conditional test.

Popular posts from this blog

Arrays in Visual Basic and classic ASP

For the programmer who is used to C-like syntax, working with arrays in Visual Basic or classic ASP can be aggravating. In this post, I will briefly go over declaring single- and multi-dimensional arrays, then iterating through them — the basic operations that make arrays useful. One-dimensional arrays Let's declare an array with six elements. Dim OneDimArray(5) Yes, that says "5", but it has six elements. When we're going through the elements of this array, we'll start counting from zero and end at five. Iterating through one-dimensional arrays For i = 0 to UBound(OneDimArray) Response.Write(i) Next There will be six elements iterated through. General notes about arrays in Visual Basic So far, we're left with the impression that Visual Basic is a strange language. When we declare arrays in VB, the real size is the declared array size plus 1. If you're used to programming in a C-like programming language such as C++ or Java, it's the declared array...
Read more

JavaScript syntax highlighters

I'm really into writing documentation, and very often, this documentation must include code samples. I wanted a JavaScript syntax highlighter that: involved very little hassle in setting up, worked like a real parser using parse trees to ensure accurate highlighting, and provided decent coverage of the most common programming languages in use today. Obviously, by opting to go with a JavaScript syntax highlighter, I chose to forgo the option of doing my syntax highlighting on the server side. Doing it on the server side still interests me, but for immediate and practical reasons, the quickest way to get syntax highlighting in my documentation would be to do it on the client side. I went searching around for JavaScript syntax highlighters, and these are the top three that met my criteria. Javascript code prettifier . This was the first decent one that I found. It's pretty basic but I got up and running very quickly. The documentation is sparse and the tone of the README quite ter...
Read more

The costs of configurable settings in your web application

By and large, the received wisdom when it comes to configurability and flexible settings for web applications is that more is better. Making something configurable frees up the engineer from having to make mundane (but necessary) changes that can be left to other people. It's desirable to change the state of software without having to rebuild or redeploy the code. There are a lot of obvious benefits to making software configurable, and these benefits are plain to all. What I'm going to focus on here are the costs of configurability, based on my experience and observations over five years of writing web applications full-time. These costs apply to other kinds of software beyond the realm of web applications. I just choose to limit the scope of discussion to web apps because these costs manifest themselves the most when there's a fast development cycle and rapid iteration. The following is intended to be a comprehensive, itemized breakdown of the costs of making an applicati...
Read more