捕獲和分析JavaScript Error的方法

2019-11-20 20:54:30

字體：大中小

來源：轉載

供稿：網友

如何捕獲和分析 JavaScript Error

前端工程師都知道 JavaScript 有基本的異常處理能力。我們可以 throw new Error()，瀏覽器也會在我們調用 API 出錯時拋出異常。但估計絕大多數前端工程師都沒考慮過收集這些異常信息。反正只要 JavaScript 出錯后刷新不復現，那用戶就可以通過刷新解決問題，瀏覽器不會崩潰，當沒有發生過好了。這種假設在 Single Page App 流行之前還是成立的?，F在的 Single Page App 運行一段時間后狀態復雜無比，用戶可能進行了若干輸入操作才來到這里的，說刷新就刷新?。恐暗牟僮髫M不要完全重做？所以我們還是有必要捕獲和分析這些異常信息的，然后我們就可以修改代碼避免影響用戶體驗。
捕獲異常的方式

我們自己寫的 throw new Error() 想要捕獲當然可以捕獲，因為我們很清楚 throw 寫在哪里了。但是調用瀏覽器 API 時發生的異常就不一定那么容易捕獲了，有些 API 在標準里就寫著會拋出異常，有些 API 只有個別瀏覽器因為實現差異或者有缺陷而拋出異常。對于前者我們還能通過 try-catch 捕獲，對于后者我們必須監聽全局的異常然后捕獲。

try-catch

如果有些瀏覽器 API 是已知會拋出異常的，那我們就需要把調用放到 try-catch 里面，避免因為出錯而導致整個程序進入非法狀態。例如說 window.localStorage 就是這樣的一個 API，在寫入數據超過容量限制后就會拋出異常，在 Safari 的隱私瀏覽模式下也會如此。

復制代碼代碼如下:

 
try { 
localStorage.setItem('date', Date.now()); 
} catch (error) { 
reportError(error); 
} 

另一個常見的 try-catch 適用場景是回調。因為回調函數的代碼是我們不可控的，代碼質量如何，會不會調用其它會拋出異常的 API，我們一概不知道。為了不要因為回調出錯而導致調用回調后的其它代碼無法執行，所以把調用回到放到 try-catch 里面是必須的。

復制代碼代碼如下:

 
listeners.forEach(function(listener) { 
try { 
listener(); 
} catch (error) { 
reportError(error); 
} 
}); 

window.onerror 

對于 try-catch 覆蓋不到的地方，如果出現異常就只能通過 window.onerror 來捕獲了。

復制代碼代碼如下:

 
window.onerror = 
function(errorMessage, scriptURI, lineNumber) { 
reportError({ 
message: errorMessage, 
script: scriptURI, 
line: lineNumber 
}); 
} 

注意不要耍小聰明使用 window.addEventListener 或 window.attachEvent 的形式去監聽 window.onerror。很多瀏覽器只實現了 window.onerror，或者是只有 window.onerror 的實現是標準的?？紤]到標準草案定義的也是 window.onerror，我們使用 window.onerror 就好了。
屬性丟失

假設我們有一個 reportError 函數用來收集捕獲到的異常，然后批量發送到服務器端存儲以便查詢分析，那么我們會想要收集哪些信息呢？比較有用的信息包括：錯誤類型（name）、錯誤消息（message）、腳本文件地址（script）、行號（line)、列號（column）、堆棧跟蹤（stack）。如果一個異常是通過 try-catch 捕獲到的，這些信息都在 Error 對象上（主流瀏覽器都支持），所以 reportError 也能收集到這些信息。但如果是通過 window.onerror 捕獲到的，我們都知道這個事件函數只有 3 個參數，所以這 3 個參數以外的信息就丟失了。
序列化消息

如果 Error 對象是我們自己創建的話，那么 error.message 就是由我們控制的?；旧衔覀儼咽裁捶胚M error.message 里面，window.onerror 的第一個參數（message）就會是什么。（瀏覽器其實會略作修改，例如加上 'Uncaught Error: ' 前綴。）因此我們可以把我們關注的屬性序列化（例如 JSON.Stringify）后存放到 error.message 里面，然后在 window.onerror 讀取出來反序列化就可以了。當然，這僅限于我們自己創建的 Error 對象。
第五個參數

瀏覽器廠商也知道大家在使用 window.onerror 時受到的限制，所以開始往 window.onerror 上面添加新的參數?？紤]到只有行號沒有列號好像不是很對稱的樣子，IE 首先把列號加上了，放在第四個參數。然而大家更關心的是能否拿到完整的堆棧，于是 Firefox 說不如把堆棧放在第五個參數吧。但 Chrome 說那還不如把整個 Error 對象放在第五個參數，大家想讀取什么屬性都可以了，包括自定義屬性。結果由于 Chrome 動作比較快，在 Chrome 30 實現了新的 window.onerror 簽名，導致標準草案也就跟著這樣寫了。

復制代碼代碼如下:

 
window.onerror = function( 
errorMessage, 
scriptURI, 
lineNumber, 
columnNumber, 
error 
) { 
if (error) { 
reportError(error); 
} else { 
reportError({ 
message: errorMessage, 
script: scriptURI, 
line: lineNumber， 
column: columnNumber 
}); 
} 
} 

屬性正規化

我們之前討論到的 Error 對象屬性，其名稱都是基于 Chrome 命名方式的，然而不同瀏覽器對 Error 對象屬性的命名方式各不相同，例如腳本文件地址在 Chrome 叫做 script 但在 Firefox 叫做 filename。因此，我們還需要一個專門的函數來對 Error 對象進行正規化處理，也就是把不同的屬性名稱都映射到統一的屬性名稱上。具體做法可以參考這篇文章。盡管瀏覽器實現會更新，但人手維護一份這樣的映射表并不會太難。

類似的是堆棧跟蹤（stack）的格式。這個屬性以純文本的形式保存一份異常在發生時的堆棧信息，由于各個瀏覽器使用的文本格式不一樣，所以也需要人手維護一份正則表達，用于從純文本中提取每一幀的函數名（identifier）、文件（script）、行號（line）和列號（column）。
安全限制

如果你也遇到過消息為 'Script error.' 的錯誤，你會明白我在說什么的，這其實是瀏覽器針對不同源（origin）腳本文件的限制。這個安全限制的理由是這樣的：假設一家網銀在用戶登錄后返回的 HTML 跟匿名用戶看到的 HTML 不一樣，一個第三方網站就能把這家網銀的 URI 放到 script.src 屬性里面。HTML 當然不可能被當做 JS 解析啦，所以瀏覽器會拋出異常，而這個第三方網站就能通過解析異常的位置來判斷用戶是否有登錄。為此瀏覽器對于不同源腳本文件拋出的異常一律進行過濾，過濾得只剩下 'Script error.' 這樣一條不變的消息，其它屬性統統消失。

對于有一定規模的網站來說，腳本文件放在 CDN 上，不同源是很正常的?，F在就算是自己做個小網站，常見框架如 jQuery 和 Backbone 都能直接引用公共 CDN 上的版本，加速用戶下載。所以這個安全限制確實造成了一些麻煩，導致我們從 Chrome 和 Firefox 收集到的異常信息都是無用的 'Script error.'。
CORS

想要繞過這個限制，只要保證腳本文件和頁面本身同源即可。但把腳本文件放在不經 CDN 加速的服務器上，豈不降低用戶下載速度？一個解決方案是，腳本文件繼續放在 CDN 上，利用 XMLHttpRequest 通過 CORS 把內容下載回來，再創建 <script> 標簽注入到頁面當中。在頁面當中內嵌的代碼當然是同源的啦。

這說起來很簡單，但實現起來卻有很多細節問題。用一個簡單的例子來說：

復制代碼代碼如下:

 
<script src="http://cdn.com/step1.js"></script> 
<script> 
(function step2() {})(); 
</script> 
<script src="http://cdn.com/step3.js"></script> 

我們都知道這個 step1、step2、step3 如果存在依賴關系的話，則必須嚴格按照這個順序執行，否則就可能出錯。瀏覽器可以并行請求 step1 和 step3 的文件，但在執行時順序是保證的。如果我們自己通過 XMLHttpRequest 獲取 step1 和 step3 的文件內容，我們就需要自行保證其順序正確性。此外不要忘記了 step2，在 step1 以非阻塞形式下載的時候 step2 就可以被執行了，所以我們還必須人為干預 step2 讓它等待 step1 完成后再執行。

如果我們已經有一整套工具來生成網站上不同頁面的 <script> 標簽的話，我們就需要調整一下這套工具讓它對 <script> 標簽做出改動：

復制代碼代碼如下:

 
<script> 
scheduleRemoteScript('http://cdn.com/step1.js'); 
</script> 
<script> 
scheduleInlineScript(function code() { 
(function step2() {})(); 
}); 
</script> 
<script> 
scheduleRemoteScript('http://cdn.com/step3.js'); 
</script> 

我們需要實現 scheduleRemoteScript 和 scheduleInlineScript 這兩個函數，并且保證它們在第一個引用外部腳本文件的 <script> 標簽之前就被定義好，然后余下的 <script> 標簽都會被改寫成上面這種形式。注意原本立即執行的 step2 函數被放到了一個更大的 code 函數里面了。code 函數并不會被執行，它只是一個容器而已，這樣使得原本 step2 的代碼不需要轉義就能保留下來，但又不會被立即執行。

接下來我們還需要實現一套完整的機制，保證這些由 scheduleRemoteScript 根據地址下載回來的文件內容和由 scheduleInlineScript 直接獲取到的代碼能夠按照正確的順序一個接一個地執行。詳細的代碼我就不在這里給出了，大家有興趣可以自己去實現。
行號反查

通過 CORS 獲取內容再把代碼注入頁面能夠突破安全限制，但會引入一個新的問題，那就是行號沖突。原本通過 error.script 可以定位到唯一的腳本文件，再通過 error.line 可以定位到唯一的行號?，F在由于都是頁面內嵌的代碼，多個 <script> 標簽并不能通過 error.script 來區分，然而每一個 <script> 標簽內部的行號都是從 1 算起的，結果就導致我們無法利用異常信息定位錯誤所在的源代碼位置。

為了避免行號沖突，我們可以浪費一些行號，使得每一個 <script> 標簽中有實際代碼所使用的行號區間互相不重疊。舉個例子來說，假設每個 <script> 標簽中的實際代碼都不超過 1000 行，那么我可以讓第一個 <script> 標簽中的代碼占用第 1亚洲香蕉成人av网站在线观看_欧美精品成人91久久久久久久_久久久久久久久久久亚洲_热久久视久久精品18亚洲精品_国产精自产拍久久久久久_亚洲色图国产精品_91精品国产网站_中文字幕欧美日韩精品_国产精品久久久久久亚洲调教_国产精品久久一区_性夜试看影院91社区_97在线观看视频国产_68精品久久久久久欧美_欧美精品在线观看_国产精品一区二区久久精品_欧美老女人bb