查找破坏 IE 的 ECMAScript/JavaScript 错误

Question

我在一个相对庞大的 ECMAScript 代码库（> 60,000 LOC）上工作，我们在检测我们可怕的朋友 Internet Explorer（尤其是 6 和 7）的错误时往往会遇到一些困难。

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

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

通常我依赖 JSLint 并且我倾向于抓住常见的嫌疑人（尾随逗号，我讨厌你），但在这种特殊情况下，我刚刚对我的所有代码（包括源代码和最小化代码）重新运行了 linter，但它并没有给出我通常的怀疑。所以我想我错误地引入了 IE 不喜欢的东西（谁知道，也许我疯了，在某个地方使用了 Array.map 而不是 dojo.map？），它在我脸上爆炸，产生了很好的错误消息，但不根本帮不了我（“[object object]”和“is null”不应该是这样，所以我假设上游有一个错误默默地失败并阻止了该对象的创建）。

我尝试过查看 Google Closure Linter，但它没有产生任何特别的结果，而且我也不认为 Google Closure Compiler 会成为我的救世主。是否有任何工具（命令行、Web 服务或其他）可以像模拟 IE 一样解析/运行代码，以便我们获得适当的错误？

任何提示表示赞赏。

编辑：感谢您迄今为止尝试解决我的问题的帮助，但我真正想问的是是否有工具可以执行此类检查，这意味着针对特定浏览器验证功能集和语法。在我看来，这是 JS 世界中严重缺乏的东西（FF 或 Chrome 则不然，显然它们的调试器更有帮助）。

EDIT2：今天（3天后）我最终找到了问题的根源，通过检查两个分支之间的所有代码更改，并意识到问题实际上已经存在，但以前从未检测到，并返回到更旧的更改以缩小范围混乱并最终在各处添加控制台日志，直到我达到故障点（上帝感谢 emacs 的正则表达式支持，将日志添加到每一行......繁重但有效......）。但有趣的事实是：IE 吞下了一条原本应该在 try catch 块中显示的错误消息，最初捕获了源问题，然后重新抛出它。仍然不知道为什么，但如果没有的话，会更容易找到，因为它就是为了这个目的，以防万一它坏了。诡异的。可能不喜欢深层次的重新抛出。

我将保留这个问题，因为目前实际问题还没有答案。

Answer 1

您可以尝试使用 IE8 调试器，正如 @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); }

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

Answer 2

您可以尝试Microsoft 脚本调试器，或Internet Explorer 开发人员工具。

有关 IE 8 与旧版本可能不同的完整列表，请参阅：

• Internet Explorer 8 准备工具包（官方列表）
• 尤其是DOM 改进
• JavaScript在 Internet Explorer 8 中 （John Resig 的帖子）

另请参阅 Web错误跟踪可能出现的怪癖。

最后一点，在每一行上执行 console.log 可能会帮助您以困难的方式找到特定的错误，但考虑到代码量，您实际上应该为模块编写单元测试。这是确保您的应用程序能够在不同的输入和条件下实际运行的唯一方法。