FE B 異常監控原理

2021-09-12 16:53:34 字數 2441 閱讀 4473

js錯誤主要有2類:語法錯誤指令碼錯誤;

監控方式有2種:try-catchwindow.onerror

try-catch處理異常的能力有限,只能捕獲到執行時的非非同步錯誤,對於語法錯誤和非同步錯誤就顯得無能為力。

try catch(e) 

//輸出:

//referenceerror: error is not defined

try  catch(e) 

//輸出:

//uncaught syntaxerror: invalid or unexpected token

try, 0)

} catch(e)

//輸出:

//uncaught referenceerror: error is not defined

window.onerror捕獲異常的能力比try-catch稍強一點,無論是非同步還是非非同步的錯誤,onerror都能捕獲到執行時的錯誤

/**

* @param msg 錯誤資訊

* @param url 出錯檔案

* @param row 行號

* @param col 列號

* @param error 錯誤詳細資訊

*/ window.onerror = function (msg, url, row, col, error) )

return true;

};error; //

//輸出:

//捕獲到錯誤了

//

window.onerror = function (msg, url, row, col, error) )

return true;

};settimeout(() => );

//輸出:

//捕獲到非同步錯誤了

//

在實際使用中,onerror主要用來捕獲預料之外的錯誤,try-catch則是用來在可預見情況下監控特定的錯誤,兩者結合使用更加高效

但是對於語法錯誤,window.onerror還是捕獲不了,所以我們在寫**的時候要盡可能避免語法錯誤,不過一般這種錯誤比較容易察覺。

除了語法錯誤不能捕獲之外,網路異常的錯誤也是不能捕獲的

這是因為網路請求是沒有事件冒泡的,所以需要在捕獲階段才能捕獲到異常,雖然這樣可以捕獲到網路的異常,但無法判斷http的狀態,比如該異常是404還是500,想要知道這個狀態就必須和服務日誌一起排查了。

我知道錯誤了

promise的錯誤沒有使用catch去捕獲的話,上述的方式都是不能捕獲到錯誤的。但通過監聽unhandledrejection事件,可以捕獲未處理的promise錯誤。但是需要注意的是,這個事件是有相容問題的。

window.addeventlistener("unhandledrejection", function(e));

new promise((resolve, reject) => );

輸出:我知道 promise 的錯誤了

promise error

說完這些捕獲異常的方式之後,該說說異常上報的常用方法了。

當我們拿到報錯資訊之後,就需要上報這些異常資訊,我們上報的方式通常有兩種方法:

通過ajax傳送資料

通過動態建立img標籤的形式

function report(error)
在乙個域下引用了其他域的指令碼,又沒有去做額外的配資,就很容易產生script error。說到最後這就是因為瀏覽器的同源策略產生的。所以最好我們還是使用跨源資源共享機制( cors )

FE B 異常監控原理

js錯誤主要有2類 語法錯誤 指令碼錯誤 監控方式有2種 try catch window.onerror try catch處理異常的能力有限,只能捕獲到執行時的非非同步錯誤,對於語法錯誤和非同步錯誤就顯得無能為力。try catch e 輸出 referenceerror error is no...

前端異常監控

前端監控包括 行為監控 異常監控 效能監控,這裡主要討論異常監控。對於前端而言,和後端處於同乙個監控系統中,前端有自己的監控方案,後端也有自己的監控方案,但兩者並不分離,因為乙個使用者在操作應用的過程中如果出現異常,有可能是前端引起,也有可能是後端引起,需要有乙個機制,將前後端串聯起來,使監控本身統...

前端異常監控實踐

前端異常監控系統的開發其實並不複雜,開源實現方案也頗多,技術實現成本並不難,痛點有但是並不是都不能解決,根據我們的情況總結了一下 捕獲使用者的操作路徑,根據操作路徑我們去還原使用者的使用場景,來幫助我們快速定位問題的所在。操作路徑分為以下幾個點 當然這塊整體的資料我們會基於cookie和locals...