查找IE中断ECMAScript/JavaScript错误

我在一个相对庞大的ECMAScript代码库（>60000 LOC）上工作，我们倾向于为我们可怕的朋友Internet Explorer（特别是6和7）检测错误

目前，我已经被一个问题困扰了3天，我的RIA在Google Chrome、Firefox 3.6、Opera和Internet Explorer 8中表现良好，但在IE7模式下运行Internet Explorer 8（或使用真正的IE-7）时失败

我的问题是：如何识别在IE7中会产生错误的代码

通常我依赖于JSLint，并且我倾向于捕捉通常的可疑对象（尾随逗号，我讨厌你），但在这种特殊情况下，我只是在我的所有代码上重新运行了一个linter，包括源代码和最小化代码，它不会产生通常的可疑对象。所以我猜我错误地引入了IE不喜欢的东西（谁知道呢，也许我疯了，在什么地方用了Array.map而不是dojo.map？）它不应该在哪里，所以我假设上游有一个错误，该错误以静默方式失败并阻止创建该对象）

我试着看一下Google闭包Linter，但它没有产生任何特别的效果，我也不认为Google闭包编译器会成为我的救星。是否有任何工具（命令行、web服务或其他）可以像模拟IE那样解析/运行代码，以便我们能够获得适当的错误

任何提示都将不胜感激

编辑：感谢您帮助我解决目前的问题，但我真正想问的是，是否有工具可以执行此类检查，即针对特定浏览器验证功能集和语法。在我看来，这是JS世界中严重缺乏的东西（FF或Chrome没有这么多，因为他们的调试器更有用）

编辑2：我今天终于找到了问题的根源（3天后）通过检查我在两个分支之间的所有代码更改，并意识到问题实际上已经存在，但以前从未检测到，然后通过更旧的更改来缩小混乱的范围，并最终在所有地方添加控制台日志，直到出现故障（感谢emacs对正则表达式的支持，它可以将日志添加到每一行中……虽然很重，但很有效……）。有趣的事实是：IE吞下了一条错误消息，该消息原本应该显示在try-catch块中，最初捕获源问题，然后重新抛出。仍然不知道为什么，但如果不是这样，那么会更容易找到，因为它是为了防止它坏掉。奇怪。可能不喜欢深层次的重新抛出

我将保留该问题，因为现在实际问题没有答案。

您可以尝试，或者

有关IE 8与旧版本可能不同之处的完整列表，请咨询：

• （官方名单）
• 特别是
• （约翰·雷西格的职位）

另请参阅以了解可能的怪癖

---

最后，在每一行上执行

console.log

可能会帮助您以一种困难的方式找到特定的bug，但考虑到您真正应该为模块编写单元测试的代码量。这是确保应用程序实际运行时具有不同输入和条件的唯一方法。

您可以尝试IE8调试ger，正如@galambalazs所建议的那样；IE6时代的旧调试器通常没有用处

我一直使用的底层技术是在Javascript源代码的很大一部分周围添加我自己的try/catch块，以缩小错误源。通过迭代调整try/catch块，您可以进行“二进制搜索”通过源代码查找导致异常的代码。您可能会发现，Firefox中有一些代码是无害的，但IE的解释器认为是错误的。（公平地说，通常情况下，IE的严格是合理的，Firefox的宽松行为是不可取的。）

换句话说，您可以从您怀疑的Javascript源代码开始，或者对所有包含的.js文件执行此操作：

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

现在，如果加载该页面并获得该警报，那么您就知道错误在foo.js中的某个地方。因此，您将其一分为二：

// 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); }

---

重复这个过程，你最终会发现问题。

真的不期待一个超过60000行的b-树搜索，老实说：）经过十次左右的迭代，你可能会开始怀疑问题在哪里。

window.onerror

会让你在没有try/catch块的情况下更接近

window.onerror=function（msg，url，line）{alert（“Error on line”+line）；}

@Pointy:在IE 7和更低版本中，这与

url

参数一起是非常不可靠的，但我使用IE 8的所有经验（我已经编写了一个onerror堆栈跟踪器）告诉我这是固定的，除了非常罕见的情况，这是一个单一的线小康马克。@安迪E是的，我同意IE8是（大部分）在这方面的所有固定，但问题是关于IE7，或IE7模式。如果IE8没有模仿IE7的特定功能（我从未尝试过），那么你是对的，这将是一个更快的方法。但是，直接依靠IE8调试器可能会更快！！如前所述，IE提供的信息在这种情况下没有多大帮助。这些错误来自集成调试器，报告这些错误是因为对象基本上不存在（它应该存在的位置），这意味着在该错误以静默方式失败之前可能遇到另一个错误。请参阅我的更新。我很确定您的问题中的msot与DOM有关。@galambalazs：在RIA呈现的这个阶段不太可能，因为错误开始发生，而我们仍然在引导和加载依赖项。但这是可能的，我会看看你的名单，然后再给你回复。谢谢。@galambalazs:绝对与DOM无关，它发生在