2

我正在考虑将我的整个 javascript 库包装在一个 try catch 块中，这样任何错误都不会导致使用该库的第三方页面中断。

此外，我还能够捕获我自己的代码引发的错误并将它们发送到我的服务器。

我唯一的问题是这样做会不会产生任何潜在的负面影响？（性能、错误跟踪等）

4

3 回答 3

3

将您的库包装在一个try{}块中并不是一个好主意。有几个不同的问题。值得注意的是，V8 无法优化 a 内部的堆栈try{}，从而导致明显的性能损失。将任何您实际上不希望throw出现错误的内容包装起来通常不是一个好习惯，因为它会从调试控制台中吞下并隐藏错误。

此外，包装库try{} catch(e) {}并不会神奇地捕获发生的每个错误。也许你的“库”只是一段加载时执行一次的 JavaScript 代码，但很可能你有某种异步操作会导致代码在try{}. 重要的是要注意这不会捕获：

try {
    setTimeout(function() {
        throw "test";
    }, 100);
} catch(e) { 
    console.log( "I got caught" );
}

在 jsFiddle 中尝试一下

幸运的是，有一个捕捉“未处理”错误的好地方——window.onerror对于“第一方”开发人员来说，保持理智是一个非常好的主意，但是当你在一个库上工作时，你应该依赖于坚如磐石的单元测试。为“第一方开发人员”提供一个明显且易于使用的错误报告表也是必须的。相信我，如果你的图书馆坏了，人们会抱怨的。:)

PS - 我在程序员 SE 上发现了这个问题，这应该能更清楚地说明try{}

PPS - 找到了一个不错的jsperf使用try{}，如果你看一下，它似乎表明包含try{}块的函数的性能会降低。

于 2012-09-16T07:29:34.293 回答
1

如果你正在吞下一个异常，你并没有阻止第三方页面被破坏——你的代码被调用并且发生了一个异常，显然页面现在被破坏了——除了现在第三方页面的开发人员不知道你的代码坏了。恕我直言，这是一个很大的缺点。如果发生了不好的事情，看在上帝的份上，让别人知道。这就是例外的原因。

于 2012-09-16T02:55:27.863 回答
0

尽管我同意 Blender 的观点，理想情况下您会尝试通过一些彻底的 QA 来跟踪任何错误，以回答您的问题“什么是不利影响”：

  • 在性能方面，try-catch 块在没有错误发生时无效。这并不取决于代码的大小。Try/catch 仅在发生错误时才会产生开销效应。并且代码的大小不会显着增加/减少这种开销。大多数情况下，错误处理将查看被捕获块的返回类型，而不是整个块（请参阅 ECMA 规范的第 96 页：）
  • @Aquinas 还有一个很好的观点，即其他第 3 方脚本需要知道该页面可能已损坏...
于 2012-09-16T03:10:36.150 回答