是否将一个函数分配给window.onerror,而不是window.addEventListener('错误',回调)?

时间:2016-06-21 00:13:02

标签: javascript error-handling

将函数分配给window.onerror似乎是一种非常简单的方法来开始处理页面代码中的错误。但是,确保您不会覆盖预先存在的错误处理程序非常重要,因此通常的做法是保持对先前值的引用并将其作为新函数的一部分进行调用。举个例子:

var old_onerror = window.onerror;
window.onerror = function() {
    // do something
    if (old_onerror) {
        old_onerror();
    }
};

我可以在网上找到的大多数文档/博客文章/等建议做这样的事情。为什么他们不建议为'error'事件添加事件处理程序呢?这允许在触发其中一个事件时调用多个函数,并且不需要笨拙地维护对其他错误处理程序的引用。

window.addEventListener('error', function() {/* do something */});

修改:我考虑过关注the standard advice on this subject,但error上的window事件似乎是一个相当特殊的情况(例如,请参阅JQuery' s {{3} }(在该页面上搜索" onerror"))。我特意寻求洞察为什么onerror似乎是一个特例。

1 个答案:

答案 0 :(得分:2)

由于历史原因,这些window.onerror有点特殊。现在大多数这些功能已经失效,我认为您必须回到IE8才能找到需要它们的浏览器。大约十年前,IE6是王者,它根本不支持addEventListener,许多事件仅受某些浏览器支持或使用不同的名称。 Web开发曾经非常不一致,并且发现像window.onerror这样的旧方法也很常见。

出于向后兼容的原因,window.onerror有点奇怪,因为预订事件的两种方式采用了不同的论点。

因此旧式onerror包含错误详细信息作为参数:

window.onerror = function(message, source, line, col, error) {
    ...

    return true; // This will prevent further event propagation
};

它仍然存在,以便已经存在的旧JS不会中断-浏览器设计师希望拥有10年历史的网站仍基本上可以在其最新版本中工作。

(现在是最佳实践)事件侦听器将它们作为事件的属性:

window.addEventListener('error', e => {

    // Get the error properties from the error event object
    const { message, source, lineno, colno, error } = e; 
});

后者要好得多,因为您不需要任何以前的侦听器,并且以后的侦听器(例如来自浏览器扩展的侦听器)都不会意外中断您的侦听器。另外,如果您要构建的SPA之类的东西停留在window上下文的一页上,则可以删除您的侦听器。

所以,要回答这个问题:

  

大多数文档/博客文章/等等,我可以在网上找到建议做这样的事情。他们为什么不建议为“错误”事件添加事件处理程序?

因为它们已经过时了。使文档保持最新是很困难的,并且JS动作很快。的 您描述的window.onerror模式在某些公司环境中仍然是可以接受的折衷方案,其中需要支持IE的版本非常过时。对于绝大多数的网络,addEventListener方法要好得多。

  

例如,参见JQuery明显缺乏对它的支持(在该页面上搜索“ onerror”

jQuery是。其中有一些决定是在2006-2008年间做出的决定,或将其永久保留,.on做出的一些假设是其中之一。 jQuery的.on在2006年很棒,因为我们不必担心不同浏览器的事件实现-它可以将所有浏览器都隐藏在一个通用界面后面。现在所有内容都使用addEventListener,因此您不需要它(它比.on强大得多)。