2016-06-09 107 views
8

我發現https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/onerror它說:服務人員如何處理全局錯誤處理?

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

但是我不能在Chrome(V51)得到這個工作。在主應用程序的範圍,我跑從控制檯下面的代碼:

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

然後主動服務工作者的我引發的任意錯誤的範圍之內:

f(); // f is undefined 

其結果是通常「未捕獲的ReferenceError:f未定義(...)」錯誤消息,但未通過全局onerror處理程序記錄。

MDN頁面顯示,自從v40版本開始,Chrome已經支持該API,但navigator.serviceWorker.onerror最初未定義,這導致我認爲它未實現。有人熟悉這個嗎?

+0

「*最初不確定*」 - 你的意思是它確實有undefined'的'的值(這是原因能夠),還是該財產根本不存在? – Bergi

+0

@Bergi它有一個'undefined'的值,這讓我覺得不尋常,因爲window.onerror最初是'null'。編輯:我加倍檢查,這也是屬性不存在''onerror'navigator.serviceWorker // false' –

回答

6

也許你試着設置onerror處理程序navigator.serviceWorker容器這樣的:

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

錯誤處理程序必須從服務工作者腳本內設置有self.onerrorself是一個特殊的變量/屬性這裏指的是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); 
}); 

這裏有一個demo。務必從DevTools>資源>服務工作者(左面板)刪除服務工作者因爲這將填補這些失敗的服務工作者註冊:

enter image description here

我已經驗證了以下瀏覽器支持onerror服務人員的實例中:

  • 鉻51(穩定)和53(金絲雀)
  • 火狐47
  • 歌劇38(穩定)和39(開發者)

UPDATE

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

我認爲這是隻爲onerror屬性爲真(也許對其他事件有作爲),我猜測該規範尚未更新,以反映商定的實施情況......

的服務人員工作組已決定從ServiceWorkerContainer到服務工人實例移動onerror,在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).

然後有後續評論在相關指示缺乏有用的爲onerror容器上的問題(slightlyoff/ServiceWorker #104):

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

感謝您的答案。所以當MDN描述ServiceWorkerContainer接口時,它指的是'self'('ServiceWorkerGlobalScope')而不是'navigator.serviceWorker'? –

+0

沒問題。我不確定情況是否如此。對於'onerror'事件處理程序恰好是這樣(也可能是其他事件)。根據我在2014年發現的GitHub討論,我相信事件實際上已經移動,但文檔沒有更新。爲了清楚起見,我會更新我的答案。 – tony19

+0

非常有趣。在這種情況下,這不僅僅是文檔沒有更新,但規範本身是不正確的:https://www.w3.org/TR/service-workers/#service-worker-container-event-handlers –