Jak działa globalna obsługa błędów w pracownikach serwisowych?

Question

znalazłem https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/onerror który mówi:

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

Jednak nie jestem w stanie uzyskać tej pracy w Chrome (V51). W zakresie aplikacji głównej, wpadłem następujący kod z konsoli:

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

Następnie w zakresie aktywnego pracownika służby ja wywołany dowolny błąd:

f(); // f is undefined 

Wynik był zwykle "Uncaught ReferenceError: f nie jest zdefiniowany (...)" komunikat o błędzie, ale nie został zalogowany przez moją globalną procedurę obsługi onerror.

Strona MDN mówi, że ten interfejs API jest obsługiwany w przeglądarce Chrome od wersji v40, ale navigator.serviceWorker.onerror jest początkowo niezdefiniowany, co prowadzi do przekonania, że ​​jest niezatwierdzony. Czy ktoś jest z tym obeznany?

Answer 1

Być może próbował ustawić obsługi onerror na pojemniku navigator.serviceWorker jak ten:

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

Handler błąd musi być ustawiony z w skrypcie Pracownik serwisu z self.onerror (self to specjalna zmienna/atrybut tutaj to odnosi się do ServiceWorkerGlobalScope). Wywołanie zwrotne onerror jest tylko komunikat o błędzie.

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

Alternatywnie, można wysłuchać pracownika serwisowego error imprezy, która obejmuje ErrorEvent zawierającą lokalizację błędu:

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

Oto demo. Pamiętaj, aby usunąć pracowników usług z DevTools> Dział> Serwis dla robotników (w lewym panelu) jak będzie wypełnić tych nieudanych rejestracji pracowników służby:

I zostały zweryfikowane następujące przeglądarki obsługują onerror wewnątrz instancji pracownika serwisu:

• Chrome 51 (stabilna) i 53 (kanarek)
• Firefox 47
• Opera 38 (stabilna) i 39 (deweloper)

---

UPDATE:

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

myślę, że to prawdziwe tylko dla atrybutu onerror (i być może dla innych wydarzeń również tam) i domyślam się, że specyfikacja nie została zaktualizowana, aby odzwierciedlić uzgodnioną implementację ...

Grupa robocza Usługi Pracownicy postanowili przenieść onerror z ServiceWorkerContainer do instancji pracowników usług, jak omówiono w 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).

A potem był kontynuacją komentarz w powiązanym Wydanie (slightlyoff/ServiceWorker #104), który wskazuje brak przydatności onerror na pojemniku:

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.