摘要:摘要堆棧是的關鍵。假設捕獲了一個異常,上報的堆棧是這個這個堆棧,你看得出問題來嗎我們發布到的腳本文件,普遍是經過壓縮的,所以堆棧可讀性相當的差。假如有下面的一個堆棧查看工具,又如何眼尖的同學,一眼就能找到問題。
摘要: 堆棧是Debug的關鍵。
原文:如何優雅地查看 JS 錯誤堆棧?
作者:小芭樂
Fundebug經授權轉載,版權歸原作者所有。
在前端,我們經常會通過 window.onerror 事件來捕獲未處理的異常。假設捕獲了一個異常,上報的堆棧是這個:
TypeError: Cannot read property "module" of undefined at Object.exec (https://my.cdn.com/dest/app.efe91e855d7432e402545e7d6c25d2d9.js:16:29828) at HTMLLIElement.(https://my.cdn.com/dest/app.efe91e855d7432e402545e7d6c25d2d9.js:25:6409) at HTMLDivElement.dispatch (https://my.cdn.com/dest/vendor.eb28ded1876760b8e90973c9f4813a2c.js:1:248887) at HTMLDivElement.y.handle (https://my.cdn.com/dest/vendor.eb28ded1876760b8e90973c9f4813a2c.js:1:245631)
這個堆棧,你看得出問題來嗎?我們發布到 CDN 的腳本文件,普遍是經過 UglifyJS 壓縮的,所以堆??勺x性相當的差。假如有下面的一個堆棧查看工具,又如何?
眼尖的同學,一眼就能找到問題。這里的 p[e] 出現了可能為 undefined 的情況。
這樣一個工具,大大提高了問題定位的效率。
好,這里不賣瓜,我們來看下這當中的實現原理。
一步步來說的話:
拿到原始堆棧字符串,使用
error-stack-parser
解析為堆棧幀,每個堆棧幀包含三個最重要的字段:
url - 源碼的 URL 地址
line - 堆棧位置行號
col - 堆棧位置列號
對于 url,我們可以用于加載源碼內容,得到 source
source 使用 UglifyJs 反向美化成多行的代碼 prettysource,并且同時生成 sourcemap
堆棧幀中的 line 和 col 通過 sourcemap 反查,得到美化后對應的 prettyline 和 prettycol
將 prettysource、prettyline、prettycol 給到 Monaco Editor 渲染,就可以得到上述截圖的效果
說那么多,不如貼代碼是吧:
var result = UglifyJS.minify(source, { output: { beautify: true }, sourceMap: { filename: "pretty.js", url: "pretty.js.map" } }); var code = result.code; var rawSourceMap = JSON.parse(result.map); var consumerPromise = new sourceMap.SourceMapConsumer(rawSourceMap); resolve( consumerPromise.then(function(consumer) { return { code: code, sourceMapConsumer: consumer } }) );
上面就是使用 UglifyJs 對壓縮代碼進行反向美化的核心代碼。下面給出 SourceMap 的使用源碼:
var code = result.code; var consumer = result.sourceMapConsumer; var position = consumer.generatedPositionFor({ source: "0", line: lineNumber, column: columnNumber }); parent.postMessage({ event: "js-prettify-callback", payload: { hash: payload.hash, result: "success", prettySource: code, prettyLineNumber: position.line, prettyColumnNumber: position.column + 1 } }, sourceOrigin);
完整源碼有興趣的讀者也可以下下來把玩把玩:
js-loader.html.zip
源碼只包含堆棧解析的實現,UI 的實現不在本文的討論之內,用 React 隨便畫一畫就好了。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/109009.html
摘要:假設捕獲了一個異常,上報的堆棧是這個這個堆棧,你看得出問題來嗎我們發布到的腳本文件,普遍是經過壓縮的,所以堆??勺x性相當的差。假如有下面的一個堆棧查看工具,又如何堆棧查看工具眼尖的同學,一眼就能找到問題。 本文由云+社區發表 在前端,我們經常會通過 window.onerror 事件來捕獲未處理的異常。假設捕獲了一個異常,上報的堆棧是這個: TypeError: Cannot read...
摘要:假設捕獲了一個異常,上報的堆棧是這個這個堆棧,你看得出問題來嗎我們發布到的腳本文件,普遍是經過壓縮的,所以堆??勺x性相當的差。假如有下面的一個堆棧查看工具,又如何堆棧查看工具眼尖的同學,一眼就能找到問題。 本文由云+社區發表 在前端,我們經常會通過 window.onerror 事件來捕獲未處理的異常。假設捕獲了一個異常,上報的堆棧是這個: TypeError: Cannot read...
摘要:假設捕獲了一個異常,上報的堆棧是這個這個堆棧,你看得出問題來嗎我們發布到的腳本文件,普遍是經過壓縮的,所以堆??勺x性相當的差。假如有下面的一個堆棧查看工具,又如何堆棧查看工具眼尖的同學,一眼就能找到問題。 本文由云+社區發表 在前端,我們經常會通過 window.onerror 事件來捕獲未處理的異常。假設捕獲了一個異常,上報的堆棧是這個: TypeError: Cannot read...
摘要:二需要處理哪些異常對于前端來說,我們可做的異常捕獲還真不少??偨Y一下,大概如下語法錯誤代碼異常請求異常靜態資源加載異常異常異常跨域崩潰和卡頓下面我會針對每種具體情況來說明如何處理這些異常。 前端一直是距離用戶最近的一層,隨著產品的日益完善,我們會更加注重用戶體驗,而前端異常卻如鯁在喉,甚是煩人。一、為什么要處理異常?異常是不可控的,會影響最終的呈現結果,但是我們有充分的理由去做這樣的事...
閱讀 2833·2021-11-25 09:43
閱讀 2476·2021-10-09 09:44
閱讀 2801·2021-09-22 15:49
閱讀 2567·2021-09-01 11:43
閱讀 2541·2019-08-30 14:16
閱讀 464·2019-08-29 17:24
閱讀 3020·2019-08-29 14:00
閱讀 1382·2019-08-29 13:05