來源：子瑜說IT 發(fā)布時間：2019-05-10 16:31:15 閱讀量：2144
前端一直是距離用戶最近的一層，隨著產(chǎn)品的日益完善，我們會更加注重用戶體驗，而前端異常卻如鯁在喉，甚是煩人。
一、為什么要處理異常？
異常是不可控的，會影響最終的呈現(xiàn)結(jié)果，但是我們有充分的理由去做這樣的事情。
1.增強用戶體驗；
2.遠程定位問題；
3.未雨綢繆，及早發(fā)現(xiàn)問題；
4.無法復(fù)線問題，尤其是移動端，機型，系統(tǒng)都是問題；
5.完善的前端方案，前端監(jiān)控系統(tǒng)；
對于 JS 而言，我們面對的僅僅只是異常，異常的出現(xiàn)不會直接導致 JS 引擎崩潰，最多只會使當前執(zhí)行的任務(wù)終止。
二、需要處理哪些異常？
對于前端來說，我們可做的異常捕獲還真不少?？偨Y(jié)一下，大概如下：
JS 語法錯誤、代碼異常
AJAX 請求異常
靜態(tài)資源加載異常
Promise 異常
Iframe 異常
跨域 Script error
崩潰和卡頓
下面我會針對每種具體情況來說明如何處理這些異常。
三、Try-Catch 的誤區(qū)
try-catch 只能捕獲到同步的運行時錯誤，對語法和異步錯誤卻無能為力，捕獲不到。
1.同步運行時錯誤：
輸出：
2.不能捕獲到語法錯誤，我們修改一下代碼，刪掉一個單引號：
輸出：
不過語法錯誤在我們開發(fā)階段就可以看到，應(yīng)該不會順利上到線上環(huán)境。
3.異步錯誤：
可以看看日志：
并沒有捕獲到異常，這是需要我們特別注意的地方。
四、window.onerror 不是萬能的
當 JS 運行時錯誤發(fā)生時，window 會觸發(fā)一個 ErrorEvent 接口的 error 事件，并執(zhí)行 window.onerror()。
首先試試同步運行時錯誤
可以看到，我們捕獲到了異常：
再試試語法錯誤呢？
控制臺打印出了這樣的異常：
竟然沒有捕獲到語法錯誤？
懷著忐忑的心，我們最后來試試異步運行時錯誤：
控制臺輸出了：
接著，我們試試網(wǎng)絡(luò)請求異常的情況：
我們發(fā)現(xiàn)，不論是靜態(tài)資源異常，或者接口異常，錯誤都無法捕獲到。
補充一點：window.onerror 函數(shù)只有在返回 true 的時候，異常才不會向上拋出，否則即使是知道異常的發(fā)生控制臺還是會顯示 Uncaught Error: xxxxx
控制臺就不會再有這樣的錯誤了：
需要注意：
onerror 最好寫在所有 JS 腳本的前面，否則有可能捕獲不到錯誤；
onerror 無法捕獲語法錯誤；
到這里基本就清晰了：在實際的使用過程中，onerror 主要是來捕獲預(yù)料之外的錯誤，而 try-catch 則是用來在可預(yù)見情況下監(jiān)控特定的錯誤，兩者結(jié)合使用更加高效。
問題又來了，捕獲不到靜態(tài)資源加載異常怎么辦？
一、window.addEventListener
當一項資源（如圖片或腳本）加載失敗，加載資源的元素會觸發(fā)一個 Event 接口的 error 事件，并執(zhí)行該元素上的onerror() 處理函數(shù)。這些 error 事件不會向上冒泡到 window ，不過（至少在 Firefox 中）能被單一的window.addEventListener 捕獲。
控制臺輸出：
由于網(wǎng)絡(luò)請求異常不會事件冒泡，因此必須在捕獲階段將其捕捉到才行，但是這種方式雖然可以捕捉到網(wǎng)絡(luò)請求的異常，但是無法判斷 HTTP 的狀態(tài)是 404 還是其他比如 500 等等，所以還需要配合服務(wù)端日志才進行排查分析才可以。
需要注意:
不同瀏覽器下返回的 error 對象可能不同，需要注意兼容處理。
需要注意避免 addEventListener 重復(fù)監(jiān)聽。
二、Promise Catch
在 promise 中使用 catch 可以非常方便的捕獲到異步 error ，這個很簡單。沒有寫 catch 的 Promise 中拋出的錯誤無法被 onerror 或 try-catch 捕獲到，所以我們務(wù)必要在 Promise 中不要忘記寫 catch 處理拋出的異常。
解決方案： 為了防止有漏掉的 Promise 異常，建議在全局增加一個對 unhandledrejection 的監(jiān)聽，用來全局監(jiān)聽Uncaught Promise Error。使用方式：
我們繼續(xù)來嘗試一下：
那如果對 Promise 不進行 catch 呢？
嗯，事實證明，也是會被正常捕獲到的。
所以，正如我們上面所說，為了防止有漏掉的 Promise 異常，建議在全局增加一個對 unhandledrejection 的監(jiān)聽，用來全局監(jiān)聽 Uncaught Promise Error。
補充一點：如果去掉控制臺的異常顯示，需要加上：
三、VUE errorHandler
四、React 異常捕獲
React 16 提供了一個內(nèi)置函數(shù) componentDidCatch，使用它可以非常簡單的獲取到 react 下的錯誤信息
UI 的某部分引起的 JS 錯誤不應(yīng)該破壞整個程序，為了幫 React 的使用者解決這個問題，React 16 介紹了一種關(guān)于錯誤邊界（error boundary)的新觀念。
需要注意的是： error boundaries 并不會捕捉下面這些錯誤。
1.事件處理器
2.異步代碼
3.服務(wù)端的渲染代碼
4.在 error boundaries 區(qū)域內(nèi)的錯誤
我們來舉一個小例子，在下面這個 componentDIdCatch(error,info) 里的類會變成一個 error boundary：
然后我們像使用普通組件那樣使用它：
componentDidCatch() 方法像 JS 的 catch{} 模塊一樣工作，但是對于組件，只有 class 類型的組件(class component )可以成為一個 error boundaries 。
實際上，大多數(shù)情況下我們可以在整個程序中定義一個 error boundary 組件，之后就可以一直使用它了！
五、iframe 異常
對于 iframe 的異常捕獲，我們還得借力 window.onerror：
一個簡單的例子可能如下：
六、Script error
一般情況，如果出現(xiàn) Script error 這樣的錯誤，基本上可以確定是出現(xiàn)了跨域問題。這時候，是不會有其他太多輔助信息的，但是解決思路無非如下：
跨源資源共享機制( CORS )：我們?yōu)?script 標簽添加 crossOrigin 屬性。
或者動態(tài)去添加 js 腳本：
特別注意，服務(wù)器端需要設(shè)置：Access-Control-Allow-Origin
此外，我們也可以試試這個-解決 Script Error 的另類思路：
簡單解釋一下：
改寫了 EventTarget 的 addEventListener 方法；
對傳入的 listener 進行包裝，返回包裝過的 listener，對其執(zhí)行進行 try-catch；
瀏覽器不會對 try-catch 起來的異常進行跨域攔截，所以 catch 到的時候，是有堆棧信息的；
重新 throw 出來異常的時候，執(zhí)行的是同域代碼，所以 window.onerror 捕獲的時候不會丟失堆棧信息；
利用包裝 addEventListener，我們還可以達到「擴展堆棧」的效果：
七、崩潰和卡頓
卡頓也就是網(wǎng)頁暫時響應(yīng)比較慢， JS 可能無法及時執(zhí)行。但崩潰就不一樣了，網(wǎng)頁都崩潰了，JS 都不運行了，還有什么辦法可以監(jiān)控網(wǎng)頁的崩潰，并將網(wǎng)頁崩潰上報呢？
崩潰和卡頓也是不可忽視的，也許會導致你的用戶流失。
利用 window 對象的 load 和 beforeunload 事件實現(xiàn)了網(wǎng)頁崩潰的監(jiān)控。
基于以下原因，我們可以使用 Service Worker 來實現(xiàn)網(wǎng)頁崩潰的監(jiān)控：
Service Worker 有自己獨立的工作線程，與網(wǎng)頁區(qū)分開，網(wǎng)頁崩潰了，Service Worker 一般情況下不會崩潰；
Service Worker 生命周期一般要比網(wǎng)頁還要長，可以用來監(jiān)控網(wǎng)頁的狀態(tài)；
網(wǎng)頁可以通過 navigator.serviceWorker.controller.postMessage API 向掌管自己的 SW 發(fā)送消息。
八、錯誤上報
1.通過 Ajax 發(fā)送數(shù)據(jù):
因為 Ajax 請求本身也有可能會發(fā)生異常，而且有可能會引發(fā)跨域問題，一般情況下更推薦使用動態(tài)創(chuàng)建 img 標簽的形式進行上報。
2.動態(tài)創(chuàng)建 img 標簽的形式:
收集異常信息量太多，怎么辦？實際中，我們不得不考慮這樣一種情況：如果你的網(wǎng)站訪問量很大，那么一個必然的錯誤發(fā)送的信息就有很多條，這時候，我們需要設(shè)置采集率，從而減緩服務(wù)器的壓力:
采集率應(yīng)該通過實際情況來設(shè)定，隨機數(shù)，或者某些用戶特征都是不錯的選擇。
九、總結(jié)
回到我們開頭提出的那個問題，如何優(yōu)雅的處理異常呢？
1.可疑區(qū)域增加 Try-Catch
2.全局監(jiān)控 JS 異常 window.onerror
3.全局監(jiān)控靜態(tài)資源異常 window.addEventListener
4.捕獲沒有 Catch 的 Promise 異常：unhandledrejection
5.VUE errorHandler 和 React componentDidCatch
6.監(jiān)控網(wǎng)頁崩潰：window 對象的 load 和 beforeunload
7.跨域 crossOrigin 解決
其實很簡單，采用組合方案，分類型的去捕獲異常，這樣基本 80%-90% 的問題都化于無形。
喜歡小編的文章可以關(guān)注小編哦~
最后，給大家推薦一個前端學習進階內(nèi)推交流群685910553（前端資料分享），不管你在地球哪個方位，
不管你參加工作幾年都歡迎你的入駐！（群內(nèi)會定期免費提供一些群主收藏的免費學習書籍資料以及整理好的面試題和答案文檔?。?/span>
如果您對這個文章有任何異議，那么請在文章評論處寫上你的評論。
如果您覺得這個文章有意思，那么請分享并轉(zhuǎn)發(fā)，或者也可以關(guān)注一下表示您對我們文章的認可與鼓勵。
愿大家都能在編程這條路，越走越遠。
13450931319
微信登錄
QQ登錄
微博登錄
售前咨詢
