[devlunch]

One of the most exciting days we’ve had all year came a few weeks ago after a routine deploy, when someone opened up the site in IE to find that nothing worked. Such is Javascript. A simple syntax error in the code can, under the right circumstances, cascade down and break all other Javascript in its path. In our case this included the popup scripts that launch our apps.

A few of us spent a couple hours trying to track the problem down to no avail. It didn’t help that most of us don’t run Windows in the first place, but even after getting set up, the error messages are less than informative. In the end, it turned out to be one character that brought our whole site down:

So no problem right? Just look at the error message and correct the offending line. But tracking it down in the code proved to be devilishly difficult, and in the end caused our users hours of frustration. It all has to do with the way that IE chooses to handle Javascript errors. Fortunately, I took away a ton of good information, including some about how Javascript works in general. So, with perfect hindsight I offer it so that others may not be doomed to walk the same path:

1. Trailing commas in object literals (hashes) are syntax errors.

An example of this:

var hash = {
  foo: 'bar',
}

Is invalid in IE because of the trailing comma, while other browsers will allow it. Keep an eye out for these. Seriously.

2. Javascript Reserved Words Can’t be Used as Hash Keys

For example:

var hash = {
  new: 'bar'

}

The keyword “new” here will cause an error in IE. To prevent this, use strings instead for your hashes, like this:

var hash = {
  'new': 'bar'
}

3. Syntax errors prevent that block of code from being executed.

Javascript begins by evaluating a block of code for syntax errors. If it finds any, it will consider that block to be invalid, and skip to the next one. Here, each “block” is a <script> tag. This could be an external file, or in-page JS. It will move on to the next <script> block as if nothing has happened and NONE of the code will be executed, either before or after the error.

4. Other errors will cause only the remainder of the block to be skipped.

Once a block of code is evaluated and determined not to have syntax errors, it will immediately begin executing the code inside. If any errors occur during this process, execution will halt, and the remainder of that block will be skipped. However, any code already executed (variable and function definitions, etc) will remain.

5. In IE, The last error that occurred will be reported after all other code has executed.

Despite the fact that any errors (both syntax errors and otherwise) will fail and skip a given block of code, the errors themselves won’t be reported until the last block of code has been run. To get a better idea of how this works, let’s look at this flow a little more closely.

Let’s say you have three blocks of code. The first contains a syntax error, the second a different error, and the third is OK. IE will handle this code in the following way:

1. First block evaluated.
2. Syntax error is found. Error is noted and the block is skipped.
3. Second block is evaluated.
4. No syntax errors are found, so block is executed.
5. Continues up to the error, which immediately halts execution and skips the block. Error is noted.
6. Code has no errors, so it is immediately executed.
7. Error noted in the SECOND block is now finally reported.

6. Error reporting is just dead wrong.

First of all, no matter where your script exists (external or inline), the error will always be reported as part of the page itself. This means that you won’t see “Line 3: script.js”, but instead “Line 3: page.html”, despite the fact that the error is in the JS file! Nevertheless, the line number given will be relative to the file itself, so “line 3″ will be the actual line 3 of the external file.

In addition, the line numbers themselves are messed up in ways I can’t even properly analyze. If I were to wager a guess, it seems almost as if the files were put through the parser, then newlines are “inferred” from where they should occur in context. And, as a final twist of irony, it seems that CRLF line breaks are evaluated twice in IE, despite being the Windows standard! That means that if you’ve been writing your HTML in a windows based editor, your Javascript error reported on line 20 is actually on line 10. Enjoy!

So, now the stage is set for total disaster, and hours of wasted energy. Let’s watch how the game plays out, shall we?

IE begins evaluating the Javascript in my page. The first script blocks at the top contain libraries for use by the rest of the page, so it starts loading those first. It hits the first few scripts, and so far no problems. However, a few lines down, it hits some code of mine that contains a trailing comma in a hash, which triggers a syntax error. IE makes a note of the error, skips the block, and moves on. The next few blocks are error-free, so they get evaluated immediately. So far, as we expected. But wait! Now a script block later in the page calls a function contained in the block that had the syntax error. That block was skipped earlier, so now the function doesn’t exist! Now THAT block errors out, and the rest of the Javascript is skipped. Now, depending on how many different blocks call that same code throughout the page, other blocks may error, expecting the code that was inside where the original syntax error occurred. Or worse, other errors may occur expecting code inside the block where the SECOND error, caused by the first error, occurred, causing a chain reaction of biblical proportions! Our original error (remember it was just a single comma!), now has us stumbling down the entire page, only to come rolling out at the other end clutching in our hands something totally useless – the LAST error message that occurred.

Having fun yet? Now let’s step it up a notch.

In addition to this puzzling state of affairs, what REALLY threw me off was our asset packager. In production we bundle up the Javascript so that it is a single Javascript file, a common practice to limit http connections for the end user. However, when working in development mode, every Javascript file comes in separately as, you guessed it, a separate block. Ironically (or perhaps tragically), although my code, complete with it’s offending comma, was being included in the Javascript code base, it wasn’t being used anywhere throughout the site! This meant that on my development machine, where each Javascript file is separated, my code came in as a separate block, caused an error, but died peacefully on its own with no dependencies to worry about. However, on production where all the Javascript is bundled, it was taking out 90% of the code base with it, as that solitary syntax error caused the entire bundled package to be skipped, and the end result was a completely unintelligible error complaining that something didn’t exist that clearly should have.

At the time, I thought something screwy was going on with the asset packager, and began there. But every time I tried to reshuffle the code to try to pinpoint the error, a completely different error was thrown, as my little comma resulted in the wanton destruction of differently sized chunks of code that the rest of the site depended on. What’s more, every page would error out slightly differently, as different dependencies were being executed in different places. Nothing made sense anymore. Eventually the possibilities were narrowed down, and I found the comma and removed it, with absolutely no confidence that it would work. But it did.

The Bottom Line

With my perfect 20-20 hindsight, I now realize that the problem boils down to two incorrect assumptions that were feeding off each other, one about Javascript itself, and the other about IE.

First, I was assuming that all Javascript is executed as a giant block. It’s not. Points 3 and 4 above are not IE specific. Each script tag is like its own environment, and an error in one block will not prevent scripts from being executed in the other.

Second, I was assuming that IE was reporting the FIRST error that occurred. This seems natural enough considering the first assumption – if a script errors, it’s now finished and what I’m left with is the point of failure. This is in fact NOT the case, however. IE is simply running through each block blindly, reporting errors as it goes along. Without an error console (which IE natively doesn’t have), all you get is the most recent error. Effectively, IE isn’t showing you the first (and hence most relevant) error that happens, it’s showing you the last.

The Solution

The first thing to remember is simply not to trust errors in IE. They’re not showing you what you want to see. However, you can MAKE them show you what you want by turning on debugging, which will raise every error as it happens. One of the best debuggers comes bundled with MS Office, and is talked about on quite a few other sites. Five minutes or so spent installing this could have saved me hours of wild goose chasing.

There are also ways to catch these kinds of errors outside IE, by running your code through JS Lint, or turning on “Strict Warnings” in Firebug, although you may get more information than you need.

In any case, although it’s painful, hopefully now being aware of WHY IE acts the way it does on errors will help deal with more emergencies in the future.