全局错误处理在服务工作者中如何工作？

也许您试图像这样onerror在navigator.serviceWorker容器上设置处理程序：

// no effect outside service worker script
navigator.serviceWorker.onerror = function() {...};

错误处理程序必须在服务工作程序脚本中使用self.onerror（self是一个特殊的变量/属性，在此引用ServiceWorkerGlobalScope）进行设置。该onerror回调只提供一条错误消息。

// inside service worker script
self.onerror = function(message) {
  console.log(message);
};

或者，您可以侦听服务人员的error事件，其中包括一个ErrorEvent包含错误位置的事件：

// inside service worker script
self.addEventListener('error', function(e) {
  console.log(e.filename, e.lineno, e.colno, e.message);
});

这是一个演示。确保从DevTools>资源>服务工作者（在左侧面板上）删除服务工作者，因为它将填充以下失败的服务工作者注册：

我已经验证了onerrorService Worker实例中的以下浏览器支持：

• Chrome 51（稳定版）和53（金丝雀）
• 火狐47
• Opera 38（稳定版）和39（开发人员）

更新：

因此，当MDN描述该ServiceWorkerContainer接口时，是指self（ServiceWorkerGlobalScope）而不是navigator.serviceWorker？

我认为这仅适用于该onerror属性（可能还适用于该属性中的其他事件），并且我猜想该规范尚未更新以反映商定的实现...

该服务人员工作组已经决定将onerror在ServiceWorkerContainer进入服务工人实例，如在GitHub的讨论（slightlyoff/ServiceWorker＃198）：

kinu于2014年4月2日评论了

sgtm2。对于错误报告（onerror内容），我们可能可以做类似的事情？例如，将.onerror处理程序从容器移动到SW对象，以便doc可以明确知道错误来自哪个SW（尽管可能需要将处理程序附加到多个SW）。

然后在一个相关的问题（slightlyoff/ServiceWorker＃104）中有一个后续评论，该评论表明onerror该容器没有用处：

jakearchibald于2014年4月3日评论了

考虑用例（从＃198开始）…

navigator.serviceWorker.onerror或navigator.serviceWorker.pending.onerror（无论它变为哪种）对于将错误记录回服务器都没有用，因为错误可能发生在任何页面的生命周期之外。onerror在工作人员内部最适合这样做。

.pending.onerror如果您要更新UI以响应更新，则很有用。因此statechange，尽管您需要在某处放置错误消息，但最好还是将它作为。

这样就可以在创建SW实例之前发生错误。AppCache的错误事件涵盖与网络相关的更新失败，也分析失败。但是，我们将再次失去在页面生命周期之外发生的所有错误。