如何优雅地查看 JS 错误堆栈?
摘要: 堆栈是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.<anonymous> (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 压缩的,所以堆栈可读性相当的差。假如有下面的一个堆栈查看工具,又如何?
眼尖的同学,一眼就能找到问题。这里的 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);
完整源码有兴趣的读者也可以下下来把玩把玩:
源码只包含堆栈解析的实现,UI 的实现不在本文的讨论之内,用 React 随便画一画就好了。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
SpringBoot 配置静态文件缓存
yml配置 spring: resources: chain: strategy: content: enabled: true paths: /** cache: true compressed: false enabled: true cache: cachecontrol: cache-public: true 增加代码配置 import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.ControllerAdvice; import org.springframework.web.bind.annotation.ModelAttribute; import org.springframework.web.servlet.resource.ResourceUrlProvider; @ControllerAdvice public class ControllerConfig { @Autowired ResourceUrlP...
- 下一篇
《深入理解Java虚拟机》-----Java内存区域与内存溢出异常——Java高级开发必须懂的
《深入理解Java虚拟机》-----Java内存区域与内存溢出异常——Java高级开发必须懂的 正文 回到顶部 2.1 概述 对于从事C、C++程序开发的开发人员来说,在内存管理领域,他们即是拥有最高权力的皇帝又是执行最基础工作的劳动人民——拥有每一个对象的“所有权”,又担负着每一个对象生命开始到终结的维护责任。 对于Java程序员来说,不需要在为每一个new操作去写配对的delete/free,不容易出现内容泄漏和内存溢出错误,看起来由JVM管理内存一切都很美好。不过,也正是因为Java程序员把内存控制的权力交给了JVM,一旦出现泄漏和溢出,如果不了解JVM是怎样使用内存的,那排查错误将会是一件非常困难的事情。 回到顶部 2.2 运行时数据区域 Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程的启动而存在,有些区域则依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范(Java SE 7版)》的规定,Java虚拟机所管理的内存将会包括以下几个运行时数据区域 2.2.1 ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS6,CentOS7官方镜像安装Oracle11G
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- 设置Eclipse缩进为4个空格,增强代码规范
- Mario游戏-低调大师作品
- MySQL8.0.19开启GTID主从同步CentOS8