javascript - 将函数分配给 window.onerror 比 window.addEventListener ('error' 回调更可取)？

Question

将函数分配给 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 ，但是 window 上的 error 事件似乎是一个相当特殊的情况(例如，参见 JQuery 的 explicit lack of support for it(在该页面上搜索“onerror”))。我特别想了解为什么 onerror 似乎是一个特例。

Answer 1

由于历史原因，这些 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, filename, lineno, colno, error } = e; 
});

后者要好得多，因为您不需要获得任何先前的监听器，而且后续的监听器(比如来自浏览器扩展)也不会意外破坏您的监听器。如果你正在构建类似 SPA 的东西，你也可以删除你的监听器，你停留在一个页面上，只有一个 window 上下文。

所以，回答这个问题:

Most documentation/blog posts/etc I can find online recommends doing something like this. Why don't they recommend adding an event handler for the 'error' event instead?

因为它们已经过时了。使文档保持最新很难，而且 JS 发展很快。这 window.onerror 您描述的模式在某些需要支持极其过时的 IE 版本的企业环境中仍然是可以接受的折衷方案。对于绝大多数网络，addEventListener 方法要好得多。

see, for example, JQuery's explicit lack of support for it (search on that page for "onerror"

jQuery 旧。有些决定是在 2006-2008 年左右做出的，现在一直沿用至今，.on 对事件做出的一些假设就是其中之一。 jQuery 的 .on 在 2006 年非常棒，因为我们不必担心不同浏览器的事件实现——它可以将它们全部隐藏在一个通用接口(interface)后面。现在一切都使用 addEventListener，因此您不需要它(而且它比 .on 强大得多)。