IE10 Error.stack 让脚本调试更加方便快捷

堆栈跟踪将转储至 catch 子句中的控制台，由于其位于堆栈的顶部，因此起源于 squareRoot 函数的错误将变得显而易见。为了调试这一问题，开发人员无需深入查看堆栈跟踪；系统已违反 squareRoot 的前置条件，而且只需查看堆栈的上一级，原因将变得十分明了：squareRoot 调用内的子表达式自身应该为 square 的参数。

调试过程中，stack 属性将有助于识别用于设置断点的代码。请记住：您还可使用其它方法来查看调用堆栈：例如，如果您将脚本调试程序设置为“捕获异常即中断”的模式，那么您可使用该调试程序来检查调用堆栈。对于部署的应用程序，您可考虑在 try/catch 内合并问题代码，以捕获失败的调用，并将其记录于服务器中。随后，开发人员可查看调用堆栈，以隔离问题区域。

DOM 异常与 Error.stack

此前，我曾注意到被引发的对象必须为 Error 或通过其原型链导致 Error。这是有意而为之；JavaScript 可支持引发任何对象，甚至包括作为异常的基元。尽管系统可捕获和检查所有这些对象，但是它们的全部用途并非包含错误或诊断信息。因此，引发过程中仅将更新错误的 stack 属性。

即便对象为 DOM 异常，它们也不包含可导致 Error 的原型链，因此它们将不包含 stack 属性。在某些应用场景中，您需要执行 DOM 操作，并希望暴露 JavaScript 兼容的错误，那么您可能希望在 try/catch 数据块内合并您的 DOM 操作代码，并在 catch 子句中引发一个新的 Error 对象：

复制代码
function causesDomError() {
try {
var div = document.createElement('div');
div.appendChild(div);
} catch (e) {
throw new Error(e.toString());
}
}

然而，您可能将考虑是否要使用该模式。这可能是最适用于实用工具库开发的模式，特别是在您考虑代码的意图是否为隐藏 DOM 操作或简单地实施某一任务的时候。如果其目的为隐藏 DOM 操作，那么合并操作并引发 Error 可能是我们需要选择的正确方式。

性能注意事项

堆栈跟踪的构造始于错误对象被引发之时；构造堆栈跟踪需要查看当前执行堆栈。为了防止遍历特大堆栈过程中出现性能问题（甚至可能出现的递归堆栈链），默认情况下，IE 仅将收集前十位的堆栈帧。然而该设置可通过将静态属性 Error.stackTraceLimit 设置为另一数值而得以配置。该设置是全局性的，而且必须在引发错误之前 进行变更，否则其将对堆栈跟踪无效。

异步异常

当某一堆栈是由异步回调（例如