2016-06-09 7 views
8

ich https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/onerror gefunden, die sagen:Wie funktioniert die globale Fehlerbehandlung bei Service-Mitarbeitern?

The onerror property of the ServiceWorkerContainer interface is an event handler fired whenever an error event occurs in the associated service workers.

jedoch nicht in der Lage, diese Funktion in Chrome (v51) Ich bin zu bekommen. Im Rahmen der Hauptanwendung, lief ich den folgenden Code aus der Konsole:

navigator.serviceWorker.onerror = function(e) { console.log('some identifiable string' + e); }; 

Dann im Rahmen des aktiven Dienst Arbeiters ich einen beliebigen Fehler ausgelöst:

f(); // f is undefined 

Das Ergebnis war die übliche "Uncaught ReferenceError: f ist nicht definiert (...)" Fehlermeldung, aber es wurde nicht über meine globale onerror Handler protokolliert.

Die MDN-Seite besagt, dass diese API seit v40 in Chrome unterstützt wird, aber navigator.serviceWorker.onerror ist zunächst undefiniert, was zu der Annahme führt, dass sie nicht implementiert ist. Kennt jemand das?

+0

„* zunächst undefiniert *“ - meinst du, es hat einen Wert von 'undefined' (der Grund fähig), oder dass die Immobilie gar nicht existiert? – Bergi

+0

@Bergi es hat einen Wert von 'undefined', was mir ungewöhnlich erscheint, weil window.onerror zunächst' null' ist. Edit: Ich habe doppelt überprüft und es ist auch der Fall, dass die Eigenschaft nicht existiert '' onerror 'in navigator.serviceWorker // false' –

Antwort

6

Vielleicht haben Sie versucht, die onerror Handler auf dem navigator.serviceWorker Container wie folgt festgelegt:

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

Die Fehlerbehandlung muss von innerhalb eines Servicemitarbeiter Skript mit self.onerror eingestellt werden (self ist eine spezielle Variable/Attribut hier bezieht sich das auf ServiceWorkerGlobalScope). Der Rückruf wird nur eine Fehlermeldung zur Verfügung gestellt.

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

Alternativ können Sie error Ereignis der Service Arbeiter hören, die eine ErrorEvent mit dem Ort des Fehlers umfasst:

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

hier ein demo. Lesen Sie bitte die Arbeiter von DevTools> Ressourcen> Dienstleister (auf dem linken Bild) löschen da sie füllen mit diesen ausgefallenen Service Arbeiter Anmeldungen:

enter image description here

ich überprüft haben die folgenden Browser unterstützen onerror innerhalb einer Instanz der Servicearbeiter:

  • Chrome 51 (stable) und 53 (Kanarienvogel)
  • Firefox 47
  • Opera 38 (stable) und 39 (Entwickler)

UPDATE:

So when MDN describes the ServiceWorkerContainer interface, that is referring to self (ServiceWorkerGlobalScope) and not navigator.serviceWorker ?

Ich denke, dass für das onerror Attribut nur wahr ist (und vielleicht auch für die anderen Veranstaltungen auch dort), und ich vermute, dass die Spezifikation nicht aktualisiert wurde, um die vereinbarte Implementierung wiederzugeben ...

Die Dienstleister Arbeitsgruppe zu bewegen onerror vom ServiceWorkerContainer in die Dienst Arbeiter Instanz entschieden hatte, wie in GitHub diskutiert (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).

Und dann gibt es einen Follow-up-Kommentar in einem verwandten Ausgabe (slightlyoff/ServiceWorker #104), die für onerror auf dem Behälter Mangel an Nützlichkeit zeigt:

jakearchibald commented on Apr 3, 2014

Thinking about the use-cases (following from #198)…

navigator.serviceWorker.onerror or navigator.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 a statechange , 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.

+0

Danke für die Antwort. Wenn also MDN die Schnittstelle ServiceWorkerContainer beschreibt, bezieht sich das auf 'self' (' ServiceWorkerGlobalScope') und nicht auf 'navigator.serviceWorker'? –

+0

Kein Problem. Ich bin mir nicht sicher, dass das unbedingt der Fall ist. Dies trifft zufällig nur auf den 'onerror'-Event-Handler zu (und vielleicht auch auf die anderen Events dort). Basierend auf einer GitHub-Diskussion, die ich seit 2014 gefunden habe, glaube ich, dass die Ereignisse tatsächlich verschoben wurden, aber die Dokumente wurden nicht aktualisiert. Ich werde meine Antwort für Klarheit aktualisieren. – tony19

+0

Sehr interessant. In diesem Fall ist es nicht nur, dass die Dokumente nicht aktualisiert wurden, aber die Spezifikation selbst ist falsch: https://www.w3.org/TR/service-workers/#service-worker-container-event-handlers –