反正只要JavaScript 出錯後刷新不復現，那用戶就可以通過刷新解決問題，瀏覽器不會崩潰，當沒有發生過好了。這種假設在Single Page App 流行之前還是成立的。現在的Single Page App 運行一段時間後狀態復雜無比，用戶可能進行了若干輸入操作才來到這裡的，說刷新就刷新啊？之前的操作豈不要完全重做？所以我們還是有必要捕獲和分析這些異常信息的，然後我們就可以修改代碼避免影響用戶體驗。
捕獲異常的方式我們自己寫的throw new Error()想要捕獲當然可以捕獲，因為我們很清楚throw寫在哪裡了。但是調用瀏覽器API 時發生的異常就不一定那麼容易捕獲了，有些API 在標準裡就寫著會拋出異常，有些API 只有個別瀏覽器因為實現差異或者有缺陷而拋出異常。對於前者我們還能通過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);
}
});
對於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.' 。
想要繞過這個限制，只要保證腳本文件和頁面本身同源即可。但把腳本文件放在不經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可以定位到唯一的行號。現在由於都是頁面內嵌的代碼，多個<script>標籤並不能通過error.script來區分，然而每一個<script>標籤內部的行號都是從1 算起的，結果就導致我們無法利用異常信息定位錯誤所在的源代碼位置。
為了避免行號衝突，我們可以浪費一些行號，使得每一個<script>標籤中有實際代碼所使用的行號區間互相不重疊。舉個例子來說，假設每個<script>標籤中的實際代碼都不超過1000 行，那麼我可以讓第一個<script>標籤中的代碼佔用第11000 行，讓第二個<script>標籤中的代碼佔用第10012000 行（前面插入1000 行空行），第三個<script>標籤種的代碼佔用第20013000 行（前面插入2000 行空行），以此類推。然後我們使用data-*屬性記錄這些信息，便於反查。
<scriptdata-src="http://cdn.com/step1.js"
data-line-start="1"
>
// code for step 1
</script>
<script data-line-start="1001">
// '/n' * 1000
// code for step 2
</script>
<script
data-src="http://cdn.com/step3.js"
data-line-start="2001"
>
// '/n' * 2000
// code for step 3
</script>
經過這樣處理後，如果一個錯誤的error.line是3005的話，那意味著實際的error.script應該是'http://cdn.com/step3.js' ，而實際的error.line則應該是5 。我們可以在之前提到的reportError函數里面完成這項行號反查工作。
當然，由於我們沒辦法保證每一個腳本文件只有1000 行，也有可能有些腳本文件明顯小於1000 行，所以其實不需要固定分配1000 行的區間給每一個<script>標籤。我們可以根據實際腳本行數來分配區間，只要保證每一個<script>標籤所使用的區間互不重疊就可以了。
瀏覽器對於不同源的內容進行的安全限制當然不僅限於<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 服務，但如果要弄明白其中的細節和原理還是必須自己親手做一次。