本文主要摘抄自:https://juejin.cn/post/7172072612430872584#heading-10,主要用来记录和学习,也推荐大家看看原博主的文章。
随着前端页面承载功能越来越多,用户本地浏览器环境也错综复杂,因此即使有完善的测试,我们也无法保证上线的代码不会出错。在这种场景下,前端页面的监控就成了各个web项目必备的工具。
常常会苦恼,平常做的项目很普通,没啥亮点;面试中也经常会被问到:做过哪些亮点项目吗?
JavaScript代码在用户浏览器中执行时,由于一些边界情况、本地环境的不可控等因素,可能会存在js运行时错误。
这篇文章是我的好朋友广胤所写,里面记录了我们2018年探索的前端监控体系的历程,由于在建设完后的我离职了,后续也没有继续能和广胤一起更进一步的探索,还是有一些些遗憾。还记得我第一次进入「兑吧」的时候,我就在简历里描述了错误监控之类的项目,其实当时我并没有在一个公司进行过实践,这大概是之前在网易的时候,闲来没事,进行的自我探索。然后进入「兑吧」后,没想到当时公司正好缺少这一块的基建,于是 TL 就让我和广胤负责了这块项目,也是这次经历让我从实习阶段就正式踏入了前端基础建设的道路,还是非常感谢这一次的机会,让我从单一的业务开发人员,转化到了结构型开发人员。记得在开发的项目的那一个月中,除了吃饭,或者和广胤讨论项目的进度问题,近乎一种忘我的开发状态。
在我司线上运行的是近亿级别的广告页面,这样线上如果裸奔,出现了什么问题不知道,后置在业务端发现,被业务方询问,这种场景很尴尬。
这是学习源码整体架构第四篇。整体架构这词语好像有点大,姑且就算是源码整体结构吧,主要就是学习是代码整体结构,不深究其他不是主线的具体函数的实现。文章学习的是打包整合后的代码,不是实际仓库中的拆分的代码。
……如果加载失败怎么办?例如,这里没有这样的脚本(error 404)或者服务器宕机(不可用)。
随着业务的快速发展,我们对生产环境下的问题感知能力越来越关注。作为距离用户最近的一层,前端的表现是否可靠、稳定、好用,很大程度上决定着用户对整个产品的体验和感受。因此,对于前端的监控不容忽视。
先来说说JavaScript的错误类型,ECMA-262 定义了 7 种错误类型,说明如下:
你以为这种错误很少吗,就我们团队就这种bug就出现好多次,被大佬骂惨了,看看我们现在线上监控到的错误
由于浏览器可以渲染DOM,JS也可以修改DOM结构,未避免冲突,JS执行的时候,浏览器DOM渲染会停止。 两段JS不能同时执行。
1. 定义window.onerror全局事件函数 window.onerror = function(message, source, lineno, colno, error) { ... } / * * message:错误信息(字符串)。可用于HTML onerror=""处理程序中的event。 * source:发生错误的脚本URL(字符串) * lineno:发生错误的行号(数字) * colno:发生错误的列号(数字) * error:Error对象 */ 是一个全局变
☞ 收集日志的方法 平时收集日志的手段,可以归类为两个方面,一个是逻辑中的错误判断,为主动判断;一个是利用语言给我们提供的捷径,暴力式获取错误信息,如 try..catch 和 window.onerror。 1. 主动判断 我们在一些运算之后,得到一个期望的结果,然而结果不是我们想要的 // test.js function calc(){ // code... return val; } if(calc() !== "someVal"){ Reporter.send({ positi
随着网页项目越来越复杂,许多异常报错很难在开发和测试阶段被发现,尽管你可能避开了语法等常规错误,但不可避免的是代码在运行时的错误你仍旧无法准确预料,假设现在有如下一段 Vue 代码,它在生命周期的 created 阶段异步请求并接收了错误的数据,可能就会导致页面渲染出现错误:
前端一直是距离用户最近的一层,随着产品的日益完善,我们会更加注重用户体验,而前端异常却如鲠在喉,甚是烦人。
对于 JS 而言,我们面对的仅仅只是异常,异常的出现不会直接导致 JS 引擎崩溃,最多只会使当前执行的任务终止。
https://juejin.cn/post/6974383324148006926
版权声明:本文为吴孔云博客原创文章,转载请注明出处并带上链接,谢谢。 https://blog.csdn.net/wkyseo/article/details/51516121
在平日的工作中前端 badjs 是一个比较常见的问题, badjs 除了我们自身业务 js 脚本里比较明显的报错外还有依赖其他资源的一些报错,对于自身业务 js 里出现的错误很容易进行定位并修复,但对于依赖资源的错误即常见的 script error (外部 js、接口错误)定位就没那么容易了。
是指用户在使用应用时,无法得到预期的结果。不同的异常带来的后果程度不同,轻则引起用户使用不悦,重则导致产品无法使用,从而使用户丧失对产品的认可。
本次写作来源于一次面试,前端架构师岗位,最后面试官临时给我掏出了一道比较少见的面试题 ,终究斩获offer ,虽然这道题并不难,但是考察的东西挺有趣,加上近期有看到前端防御性编程、优雅处理前端错误的文章,于是想起来把这道题写了下来。
在前端的开发工作当中,我们对于异常的处理可能关注的不是太多,因为js有基本的异常处理能力,很多错误会直接抛出来,打开控制台就能看到。但是如果因为异常导致网站卡死,甚至崩溃无法继续进行下去,对于用户的体验是相当差的,我们应该及时的捕获这些异常,对用户进行一些简要的温馨提示,并将异常进行及时的上报,以便于快速解决。
资源类异常的表现为, 页面空白, 未显示出想要的效果, 排版错误 等. 如果只是样式文件出现问题, 本身并不影响使用, 似乎不应该排在影响程度最大的位置. 但是由于现在的前端站点已经越来越多的采用React, Angular, Vue之类的前端框架, 导致页面几乎都是由JS生成的, 如果资源类引用错误, 将直接导致页面无法渲染(在这里, 我们只讨论CSR的情况, SSR另当别论)
笔者负责的是京喜的前端某业务,长期受到大量异常的困扰,又常常找不到原因。有时异常一下暴涨,又降了回去,定位不到问题,深受其扰。经过长时间的沉淀,分析总结出了一套结论和方法。
1. 业界案例 目前前端性能监控系统大致为分两类:以GA为代表的代码监控和以webpagetest为代表的工具监控。 代码监控依托于js代码并部署到需监控的页面,手动计算时间差或者使用浏览器的的API进行数据统计。 影响代码监控数据的因素有以下几种: 浏览器渲染机制; 浏览器对API的实现程度,比如performance API; 工具监控不用将统计代码部署到页面中,一般依托于虚拟机。以webpageTest为例,输入需统计的url并且选择运行次url的浏览器版本,webpageTest后台虚拟机对url进
包含该行的函数 //如果当前函数是有名函数,则返回其名字,如果是匿名函数则返回被赋值的函数变量名,如果是闭包中匿名函数则返回“anonymous”。 var getFnName = function
err指代 error 对象,info是一个 Vue 特有的字符串,vm指代 Vue 应用本身。记住在一个页面你可以有多个 Vue 应用。这个 error Handler 作用到所有的应用。
开发阶段,通过详细的报错信息,我们可以快速定位并解决问题。在生产,通过异常监控,根据异常埋点信息,我们可以第一时间知道异常信息,不至于造成严重后果。
这是第 89 篇不掺水的原创,想要了解更多,请戳上方蓝色字体:政采云前端团队 关注我们吧~ 本文首发于政采云前端团队博客:前端异常的捕获与处理 https://www.zoo.team/arti
来源:子慕大诗人 http://www.cnblogs.com/1wen/p/7942608.html 导火索 有一天一个测试同事的一个移动端页面白屏了,看样子是页面哪里报错了。 我自己打开页面并没有报错,最后发现报错只存在于他的手机,移动端项目又是在微信环境下,调试起来会比较麻烦,最后用他手机调试才发现问题: 是他账户下面有个对话的消息数据有问题导致页面报错了。 一般遇到这种情况只有用他的手机或者账户调试能很快查到问题,如果是外部的用户怎么办,我没法拿他的手机去测试。 📷 其实这个问题很常见,但是这次我觉
英文:mknichel 译文:Jocs https://github.com/Jocs/jocs.github.io/issues/1
前言 编程时我们往往拿到的是业务流程正确的业务说明文档或规范,但实际开发中却布满荆棘和例外情况,而这些例外中包含业务用例的例外,也包含技术上的例外。对于业务用例的例外我们别无它法,必须要求实施人员与用户共同提供合理的解决方案;而技术上的例外,则必须由我们码农们手刃之,而这也是我想记录的内容。 我打算分成《前端魔法堂——异常不仅仅是try/catch》和《前端魔法堂——调用栈,异常实例中的宝藏》两篇分别叙述内置/自定义异常类,捕获运行时异常/语法异常/网络请求异常/PromiseRejection事件,
bug是不可能被全部测试出来的,由于成本和上线档期的考虑,测试无法做到“面面俱到”,即使时间充裕也总会有这样或那样的bug埋藏在某个角落。
JavaScript的异常主要使用try catch finally语句以及窗口对象window的onerror事件来捕获。
这几天心血来潮,想了解一下前端监控的相关知识,可是在查看了很多资料之后,发现没有详细介绍前端监控的相关文章,都是讲个大概,反倒是现成的前端监控工具有不少。
以 init 为程序的入口,代码中所有同步执行出现的错误都会被捕获,这种方式也可以很好的避免程序刚跑起来就挂。
通常情况下我们不会遇到前端性能监控的需求,但是当我们的关键项目真的有这个需求的时候应该怎么做呢?
做了那么多项目,后端的日志系统是必须的,前端的日志系统倒是从来没做过。如果有机会,倒是很想试试,今天
自 HTML5 标准正式发布之后,其得天独厚的跨平台特性吸引了众多开发者的目光。 伴随着 HTML5 的发展,JavaScript 的重要性也在逐步增加,要说现在哪门语言最火的话,那一定是 JavaScript 了。 学了JavaScript 成为全栈工程师,迎娶白富美,步入人生巅峰,想想也是醉了。 但有个问题:很多开发者却并未考虑过收集 JavaScript 出错时抛出的异常信息。因为只要 JavaScript 异常后 App 不会崩溃,当没有发生过就好了。 或许,在浏览器时代,让用户刷新下页面,可以
最近杂七杂八的事情比较多,难得抽出时间来弥补一下之前的系列,欠大家的埋点系列现在开始走起来
移动Web开发过程中,在真机测试时,往往会遇到一些PC调试无法重现的问题,这时候我们需要在手机上拦截错误,并有相应的输出。 公司和网上都有类似的工具/类库,但如果纯粹一个简单的调试,或许不需要引入工具或类库,我们只需要知道全局拦截的原理。 其实很简单,就是window.onerror 语法: onerror=handleErr function handleErr(msg,url,l) { //Handle the error here return true or false } 浏览器是否显示标准的
https://juejin.cn/post/6965022635470110733
领取专属 10元无门槛券
手把手带您无忧上云