【问题标题】:Why don't JavaScript libraries use try-catch blocks more often?为什么 JavaScript 库不更频繁地使用 try-catch 块?
【发布时间】:2013-07-31 21:55:42
【问题描述】:

我对 JavaScript 还是比较陌生,来自更经典的(即 Java,也是 ActionScript 3.0)背景。我发现库/框架 API 的错误实现很常见,会进一步破坏调用堆栈,而没有明确表明它是应用程序代码(而不是库代码)破坏了东西。

例如,一个 jQuery.trigger() 调用可能会调用一个抛出错误的处理程序,并且该调用没有包装在 try-catch 中(也没有实现任何其他类型的错误保护),并阻止所有其他处理程序开火。

我理解一个错误应该停止执行,但似乎库代码可以更好地从应用程序代码沙盒化,我在 JS 库中看到这种破坏比在其他语言中更频繁合作过。

【问题讨论】:

  • 一个词:性能。

标签: javascript error-handling try-catch libraries


【解决方案1】:

首先,因为捕获单个异常很痛苦:

try {
    doSomething();
} catch(e) {
    if (e instanceof SomeException) {
        // handle SomeException
    } else {
        throw e; // and lose stacktrace information :-(
    }
}

捕获所有异常通常是错误的。

其次,因为 JavaScript 本身的异常层次结构在区分不同类型的错误和提供有关它们的信息属性方面非常差。 JavaScript 更喜欢做一些你可能想要做的事情,然后悄悄地中断,而不是引发错误(参见 undefined 等人)。历史上浏览器之间也不一致(尤其是 DOM 异常)。这意味着没有使用异常的文化,并且会继承到库设计中。

【讨论】:

  • @Mike:呵呵。 jQuery 是在实际 JS 中如何使用异常的一个很好的例子:它使用 catch-all 来获取浏览器实现错误,否则这些错误是无法被嗅探的。
【解决方案2】:

bobince 所说的,即使在你的函数中提及try-catch 目前也意味着该函数中的任何内容都不会被优化。请参阅here,注意 JSPerf 并不意味着显示幅度,优化和未优化代码之间的差异可能高达 1000 倍(或其他)。您可以在测试中添加更多代码,您应该会看到相对差异越来越大。

V8 sourceSpiderMonkey bug

这与 e.g. 完全不同。在 Java 中,仅提及 try-catch 并不会真正影响性能,而是在实际发生异常时您需要付费(然后没关系)

【讨论】:

    猜你喜欢
    • 2012-09-18
    • 2011-01-01
    • 1970-01-01
    • 2011-07-25
    • 1970-01-01
    • 2021-05-13
    • 1970-01-01
    • 2012-01-02
    • 1970-01-01
    相关资源
    最近更新 更多