瀏覽器中捕獲和分析javascript錯誤捕獲經

對於javascript的出錯，例如xxx undefined,SyntaxError等，我們是再熟悉不過的了，本文我們來討論關於javascript出錯如何捕獲。

我們team將出現錯誤的javascript代碼取名為badjs，也有一個開源的badjs項目，用於捕獲和分析js錯誤，並提供了一些基礎的報表資料分析。

捕獲錯誤一般有兩種方式：

    使用window.onerror()捕獲全域的js錯誤資訊
    使用try{...}catch(e){...}包裹需要執行的代碼，擷取error對象的屬性定位錯誤並上報

第一種方式最簡單，但當執行的js代碼和我們的網站在不同域即跨域時，由於瀏覽器的安全限制，onerror()方法只能捕獲到一個固定的錯誤碼Script error.。 具體可參考這裡：點擊查看

我們團隊目前的業務基本都會將靜態資源部署到cdn伺服器，和網站處於不同域，所以需要解決跨域問題。

跨域問題可以通過伺服器端設定access-control-allow-orgin:*解決，但並不完美。這個問題更深入的資訊可以參考這裡：https://github.com/BetterJS/badjs-report/issues/3

第二種方式是手動包裹一些要檢測的代碼，沒有跨域問題並且可以擷取到err的對象的詳細出錯資訊。 這種方式相對麻煩一些，但可以通過全域的hook，處理大部分情況，免除每次手動寫try...catch的煩惱。

我們都知道js代碼的執行是通過事件和定時器觸發執行的，所以理論上將事件觸發時的回調、定時器的回調包裹即可。

我們的badjs項目主要是通過第二種方式實現，並根據現有的業務，對以下幾種方法進行了處理：

    define(),require()等方法
    jQuery封裝的一些事件，如$.event.add,$.event.remove,ajax等
    setTimeout setInterval等

這裡處理的原理比較簡單，類似下面的代碼：

function define(){
    ...
}
var a = define;
define = function(){
    try{
        a.apply(this,arguments);
    }catch(e){
        ...錯誤上報
    }
};

這裡還有一些相容性的問題需要處理，例如在ie低版本中setTimtout和setInterval方法並不是function類型，而是object，所以無法使用改寫function的方式進行包裹。類似的還有document.attachEvent方法也是object，不是function。

除了對以上方法的單獨處理外，還有一些意外情況無法處理，例如：

    window.onload,Image.prototype.onerror等瀏覽器和dom的事件,這類方法無法直接改寫function
    第三方的外掛程式的自訂事件，如flash播放器提供的一些用於播放控制的事件。
    新的一些api，如FileReader.prototype.onload等

這些意外情況很難做全域的hook，所以只好手動try...catch。 我們的badjs也提供了一個便捷的api，例如原始碼是這樣：

var img = new Image();
img.onload = function(){
    ...
};

使用tryjs包裹

var img = new Image();
img.onload = tryJs.spyCustom(function(){
    ...
});

除此之外，try...catch能擷取的err對象在各不同的瀏覽器之間，也有一些差異。好在有人已經做一個頁面展示詳細的差異，參考url: http://broofa.com/tests/ErrorProperties.htm。
一些其他的補充

回到捕獲js錯誤這件事本身，是為了更好的監控並定位錯誤，協助我們改善代碼品質，所以kael也提到另外一個思路，可以灰階一部分使用者，直接使用主域而不是cdn的js，直接避免跨域問題，這個思路也值得一試。

另外，錯誤上報資料和訪問量等資料如果到結合一起分析，不僅可以更快速的定位問題，甚至可以實現監控自動警示等，當然這個也非常複雜。




如何在瀏覽器中捕獲和分析JavaScript Error

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

捕獲異常的方式

我們自己寫的 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 就是由我們控制的。基本上我們把什麼放進 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 上，不同源是很正常的。現在就算是自己做個小網站，常見架構如 jQuery 和 Backbone 都能直接引用公用 CDN 上的版本，加速使用者下載。所以這個安全限制確實造成了一些麻煩，導致我們從 Chrome 和 Firefox 收集到的異常資訊都是無用的 'Script error.'。

CORS

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

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


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

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


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

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

行號反查

通過 CORS 擷取內容再把代碼注入頁面能夠突破安全限制，但會引入一個新的問題，那就是行號衝突。原本通過 error.script 可以定位到唯一的指令檔，再通過 error.line可以定位到唯一的行號。現在由雩都是頁面內嵌的代碼，多個 <script> 標籤並不能通過error.script 來區分，然而每一個 <script> 標籤內部的行號都是從 1 算起的，結果就導致我們無法利用異常資訊定位錯誤所在的原始碼位置。

為了避免行號衝突，我們可以浪費一些行號，使得每一個 <script> 標籤中有實際代碼所使用的行號區間互相不重疊。舉個例子來說，假設每個 <script> 標籤中的實際代碼都不超過 1000 行，那麼我可以讓第一個 <script> 標籤中的代碼佔用第 1?1000 行，讓第二個<script> 標籤中的代碼佔用第 1001?2000 行（前面插入 1000 行空行），第三個<script> 標籤種的代碼佔用第 2001?3000 行（前面插入 2000 行空行），以此類推。然後我們使用 data-* 屬性記錄這些資訊，便於反查。

經過這樣處理後，如果一個錯誤的 error.line 是 3005 的話，那意味著實際的error.script 應該是 'http://cdn.com/step3.js'，而實際的 error.line 則應該是5。我們可以在之前提到的 reportError 函數裡面完成這項行號反查工作。

當然，由於我們沒辦法保證每一個指令檔只有 1000 行，也有可能有些指令檔明顯小於 1000 行，所以其實不需要固定分配 1000 行的區間給每一個 <script> 標籤。我們可以根據實際指令碼行數來分配區間，只要保證每一個 <script> 標籤所使用的區間互不重疊就可以了。

crossorigin 屬性

瀏覽器對於不同源的內容進行的安全限制當然不僅限於 <script> 標籤。既然XMLHttpRequest 可以通過 CORS 來突破這個限制，為什麼直接通過標籤引用的資源就不可以呢？這當然是可以的。

針對 <script> 標籤引用不同源指令檔的限制同樣作用於 <img> 標籤引用不同源圖片檔案。如果一個 <img> 標籤是不同源的話，一旦在 <canvas> 繪圖時用到了，該 <canvas>將變為唯寫狀態，保證網站不能通過 JavaScript 竊取未授權的不同源圖片資料。後來<img> 標籤通過引入 crossorigin 屬性解決了這個問題。如果使用crossorigin="anonymous"，則相當於匿名 CORS；如果使用 `crossorigin=“use-credentials”，則相當於帶認證的 CORS。

既然 <img> 標籤能這樣做，為什麼 <script> 標籤就不能這樣做？於是瀏覽器廠商就為<script> 標籤加入了同樣的 crossorigin 屬性用於解決上述安全限制問題。現在 Chrome 和 Firefox 對這個屬性的支援是完全沒有問題的。Safari 則會把crossorigin="anonymous" 當做 crossorigin="use-credentials" 處理，結果是如果伺服器只支援匿名 CORS 則 Safari 會當做認證失敗。由於 CDN 伺服器出於效能的考慮被設計為只能返回靜態內容，不可能動態根據請求返回認證 CORS 所需的 HTTP Header，Safari 相當於不能利用此特性來解決上述問題。

總結

JavaScript 異常處理看起來很簡單，跟其它語言沒什麼區別，但真的要把異常都捕獲瞭然後對屬性做分析，其實還不是那麼容易的事情。現在儘管有一些第三方服務提供捕獲 JavaScript 異常的類 Google Analytics 服務，但如果要弄明白其中的細節和原理還是必須自己親手做一次。