Find IE-breaking ECMAScript/JavaScript errors

I work on a relatively huge ECMAScript codebase (> 60,000 LOC) and we tend to struggle a bit with detecting errors for our dreaded friend Internet Explorer (especially 6 and 7).

At the moment, I've been stuck with an issue for 3 days where my RIA renders fine in Google Chrome, Firefox 3.6, Opera and Internet Explorer 8, but fails when running Internet Explorer 8 in IE7-Mode (or with a real IE-7).

My question really is: how do you do to identify code that will produce an error in IE7?

Usually I rely on JSLint and I tend to catch the usual suspects (trailing commas, I loathe you), but in this particular case I have just re-run a linter on all my code, both source and minimized, and it doesn't yi开发者_StackOverflow社区eld my usual suspects. So I guess I have mistakenly introduced something that IE doesn't like (who knows, maybe I got crazy and used Array.map instead of dojo.map somewhere?) and it blows up in my face, producing nice error messages that don't help me at all ("[object object]" and " is null" where it shouldn't be, so I assume there was an error up-stream that failed silently and prevented this object from being created).

I've tried having a look at the Google Closure Linter but it doesn't yield anything special, and I don't think that the Google Closure Compiler is going to be my savior either. is there any tool (command-line, web-service or other) that can parse/run code as if it were emulating IE so we can get the appropriate errors?

Any tips are appreciated.

EDIT: Thank you for your help in trying to solve my issue so far, but what I am really just asking is if there are tools that do this sort of checks, meaning validating a feature set and syntax against a particular browser. This is the sort of thing severly lacking in the JS-world in my opinion (not so much for FF or Chrome, obviously as their debuggers are a bit more helpful).

EDIT2: I eventually found the root of my problem today (after 3 days) by going through all my code changes between two branches and realizing that the problem was actually already there but never detected before and going back through even older changes to narrow down the mess and eventually end up adding console logs everywhere until I reached a point of failure (God thank emacs for its regular expression support to add logs to every single line... heavy but works...). Fun fact though: IE swallowed an error message supposed to be displayed in the try catch block originally catching the source problem and then re-throwing it. Still don't why, but if it hadn't then that would have been a lot easier to find, as it was intended for that purpose in case it broke. Weird. Might not like deep-levels of re-throw.

I'll leave the question open as for now there are no answer to the actual question.

You might try the IE8 debugger, as @galambalazs suggests; the old debugger from the IE6 era was generally not useful.

The low-level technique I've always used is to add my own try/catch blocks around large portions of the my Javascript source to narrow down the source of error. By iteratively adjusting your try/catch blocks you can do a "binary search" through your source to locate the code that's causing an exception. What you'll probably find is that there's some code that's harmless in Firefox but which IE's interpreter considers an error. (To be fair, it's usually the case that IE's strictness is justified, and that the lax behavior of Firefox is really undesirable.)

So in other words, you'd start on a Javascript source that you suspect, or perhaps you'd do this to all of your included .js files:

// top of Javascript source file foo.js
try {
  // ... all the code ...
} catch (x) { alert("Error in foo.js: " + x); }

Now, if you load the page and get that alert, then you know that the error is somewhere in foo.js. Thus, you split it in half:

// top of foo.js
try {
  // ... half the code, roughly ...
}
catch (x) { alert("Error in first half of foo.js: " + x); }
try {
  // ... the rest of the code ...
} catch (x) { alert("Error in second half of foo.js: " + x); }

Repeat that process and you'll eventually find the problem.

You may try Microsoft Script Debugger, or Internet Explorer Developer Tools.

For complete list of what may be different in IE 8 from the older version consult with:

• Internet Explorer 8 Readiness Toolkit (offical list)
• especially DOM Improvements
• JavaScript in Internet Explorer 8 (John Resig's post)

Also see Web Bug Track for possible quirks.

As a final note, doing console.log on every line may help you to find a particular bug in a hard way, but considering the amount of code you should really write unit test for modules. That's the only way you can make sure that your application will actually run with different inputs and conditions.