全局错误处理如何在服务工作者中工作? [英] How does global error handling work in service workers?
问题描述
我找到了
我已验证以下浏览器支持 onerror
在服务工作者的实例中:
- Chrome 51(稳定)和53(金丝雀)
- Firefox 47
- Opera 38(稳定)和39(开发人员)
更新:
因此,当MDN描述
时ServiceWorkerContainer
接口,指的是self
(ServiceWorkerGlobalScope
)而不是navigator.serviceWorker
?
我认为这只适用于一个rror
属性(也许还有其他事件),我猜测规范还没有更新以反映商定的实施......
Service Workers工作组已决定将 ServiceWorkerContainer
中的 onerror
移至服务工作者实例,如GitHub中所述( slightlyoff / ServiceWorker
#198 ):
kinu 于2014年4月2日发表评论
sgtm2。对于错误报告(
onerror
),我们可能会做类似的事情吗?例如。从容器到SW对象移动.onerror
处理程序,以便doc可以明确知道错误来自哪个SW(尽管可能需要将处理程序附加到多个SW)。 / p>
然后在相关问题中有后续评论( slightlyoff / ServiceWorker
#104 )表示<$ c缺乏实用性容器上的$ c> onerror :
jakearchibald 4月3日评论, 2014
考虑用例(来自#198 )...
navigator.serviceWorker.onerror
或navigator.serviceWorker.pending.onerror
(无论哪个)都无法将错误记录回服务器,因为错误可以发生在任何页面的生命之外。工人本身内的onerror
最适合。
.pending.onerror 如果您要更新UI以响应更新,则code>非常有用。所以也许它作为一个
statechange
更好,虽然你需要在某处放置错误信息。
在创建SW实例之前发生的错误。 AppCache有一个错误事件,它涵盖与网络相关的更新失败,并且还解析失败。但是,我们再次失去在页面生命周期之外发生的任何错误。
I found https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/onerror which says:
The onerror property of the ServiceWorkerContainer interface is an event handler fired whenever an error event occurs in the associated service workers.
However I'm not able to get this working in Chrome (v51). In the scope of the main application, I ran the following code from the console:
navigator.serviceWorker.onerror = function(e) { console.log('some identifiable string' + e); };
Then within the scope of the active service worker I triggered an arbitrary error:
f(); // f is undefined
The result was the usual "Uncaught ReferenceError: f is not defined(…)" error message but it was not logged through my global onerror handler.
The MDN page says that this API has been supported in Chrome since v40, but navigator.serviceWorker.onerror
is initially undefined which leads me to believe that it's unimplemented. Is anyone familiar with this?
Perhaps you tried to set the onerror
handler on the navigator.serviceWorker
container like this:
// no effect outside service worker script
navigator.serviceWorker.onerror = function() {...};
The error handler must be set from within a service worker script with self.onerror
(self
is a special variable/attribute here that refers to ServiceWorkerGlobalScope
). The onerror
callback is only provided an error message.
// inside service worker script
self.onerror = function(message) {
console.log(message);
};
Alternatively, you could listen to the service worker's error
event, which includes an ErrorEvent
containing the location of the error:
// inside service worker script
self.addEventListener('error', function(e) {
console.log(e.filename, e.lineno, e.colno, e.message);
});
Here's a demo. Be sure to delete the service workers from DevTools > Resources > Service Workers (on left panel) as it will fill with these failed service worker registrations:
I've verified the following browsers support onerror
within an instance of service worker:
- Chrome 51 (stable) and 53 (canary)
- Firefox 47
- Opera 38 (stable) and 39 (developer)
UPDATE:
So when MDN describes the
ServiceWorkerContainer
interface, that is referring toself
(ServiceWorkerGlobalScope
) and notnavigator.serviceWorker
?
I think that's only true for the onerror
attribute (and maybe for the other events there as well), and I'm guessing the spec hasn't been updated to reflect the agreed upon implementation...
The Service Workers working group had decided to move onerror
from the ServiceWorkerContainer
into the service worker instance, as discussed in GitHub (slightlyoff/ServiceWorker
#198):
kinu commented on Apr 2, 2014
sgtm2. For error reporting (
onerror
stuff) we could probably do similar? E.g. moving.onerror
handler from container to SW object, so that doc can explicitly know which SW the error is coming from (though it may need to attach handlers to multiple SWs).
And then there was a follow-up comment in a related issue (slightlyoff/ServiceWorker
#104) that indicates lack of usefulness for onerror
on the container:
jakearchibald commented on Apr 3, 2014
Thinking about the use-cases (following from #198)…
navigator.serviceWorker.onerror
ornavigator.serviceWorker.pending.onerror
(whichever it becomes) are not useful for logging errors back to the server, as errors can happen outside of the life of any page.onerror
inside the worker itself is best for that.
.pending.onerror
is useful if you're updating the UI in response to an update. So maybe it's better as astatechange
, although you'd need somewhere to put the error message.That leaves errors that happen before the SW instance is created. AppCache has an error event that covers network-related update failures, and also parse failures. However, once again we'd lose any errors that happened outside the life of a page.
这篇关于全局错误处理如何在服务工作者中工作?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!