前端异常处理最佳实践（转）

本文转自前端社，https://mp.weixin.qq.com/s/l2IPFiYIEXhwfZbjfeqKMw本身保存记录。前端

前端能够说是最贴近用户的一层，当产品不断的迭代完善，产品的用户体验会更加趋向于完美，然而前端异常倒是很另人头疼的一个问题，咱们应该怎么去对待这些异常呢？react

1、为何要处理异常？

异常是不可控的，会影响最终的呈现结果，可是咱们有充分的理由去作这样的事情。
跨域

加强用户体验；promise
远程定位问题；浏览器
未雨绸缪，及早发现问题；服务器
没法复线问题，尤为是移动端，机型，系统都是问题；markdown
完善的前端方案，前端监控系统；网络

对于 JS 而言，咱们面对的仅仅只是异常，异常的出现不会直接致使 JS 引擎崩溃，最多只会使当前执行的任务终止。
异步

2、须要处理哪些异常？

对于前端来讲，咱们可作的异常捕获还真很多。总结一下，大概以下：函数

JS 语法错误、代码异常
AJAX 请求异常
静态资源加载异常
Promise 异常
Iframe 异常
跨域 Script error
崩溃和卡顿

下面我会针对每种具体状况来讲明如何处理这些异常。

3、Try-Catch 的误区

try-catch 只能捕获到同步的运行时错误，对语法和异步错误却无能为力，捕获不到。

一、同步运行时错误：

输出：

二、不能捕获到语法错误，咱们修改一下代码，删掉一个单引号：

输出：

不过语法错误在咱们开发阶段就能够看到，应该不会顺利上到线上环境。

三、异步错误

能够看看日志：

并无捕获到异常，这是须要咱们特别注意的地方。

4、window.onerror 不是万能的

当 JS 运行时错误发生时，window 会触发一个 ErrorEvent 接口的 error 事件，并执行 window.onerror()。

一、首先试试同步运行时错误

能够看到，咱们捕获到了异常：

二、再试试语法错误呢？

控制台打印出了这样的异常：

居然没有捕获到语法错误？

三、怀着忐忑的心，咱们最后来试试异步运行时错误：

控制台输出了：

四、接着，咱们试试网络请求异常的状况：

咱们发现，不管是静态资源异常，或者接口异常，错误都没法捕获到。

补充一点：window.onerror 函数只有在返回 true 的时候，异常才不会向上抛出，不然即便是知道异常的发生控制台仍是会显示 Uncaught Error: xxxxx

控制台就不会再有这样的错误了：

须要注意：

onerror 最好写在全部 JS 脚本的前面，不然有可能捕获不到错误；
onerror 没法捕获语法错误；

到这里基本就清晰了：在实际的使用过程当中，onerror 主要是来捕获预料以外的错误，而 try-catch 则是用来在可预见状况下监控特定的错误，二者结合使用更加高效。

问题又来了，捕获不到静态资源加载异常怎么办？

1、window.addEventListener

当一项资源（如图片或脚本）加载失败，加载资源的元素会触发一个 Event 接口的 error 事件，并执行该元素上的onerror() 处理函数。这些 error 事件不会向上冒泡到 window ，不过（至少在 Firefox 中）能被单一的window.addEventListener 捕获。

控制台输出：

因为网络请求异常不会事件冒泡，所以必须在捕获阶段将其捕捉到才行，可是这种方式虽然能够捕捉到网络请求的异常，可是没法判断 HTTP 的状态是 404 仍是其余好比 500 等等，因此还须要配合服务端日志才进行排查分析才能够。

须要注意：

不一样浏览器下返回的 error 对象可能不一样，须要注意兼容处理。
须要注意避免 addEventListener 重复监听。

2、Promise Catch

在 promise 中使用 catch 能够很是方便的捕获到异步 error ，这个很简单。没有写 catch 的 Promise 中抛出的错误没法被 onerror 或 try-catch 捕获到，因此咱们务必要在 Promise 中不要忘记写 catch 处理抛出的异常。

解决方案： 为了防止有漏掉的 Promise 异常，建议在全局增长一个对 unhandledrejection 的监听，用来全局监听Uncaught Promise Error。使用方式：

咱们继续来尝试一下：

那若是对 Promise 不进行 catch 呢？

嗯，事实证实，也是会被正常捕获到的。

因此，正如咱们上面所说，为了防止有漏掉的 Promise 异常，建议在全局增长一个对 unhandledrejection 的监听，用来全局监听 Uncaught Promise Error。

补充一点：若是去掉控制台的异常显示，须要加上：

3、VUE errorHandler

4、React 异常捕获

React 16 提供了一个内置函数 componentDidCatch，使用它能够很是简单的获取到 react 下的错误信息

UI 的某部分引发的 JS 错误不该该破坏整个程序，为了帮 React 的使用者解决这个问题，React 16 介绍了一种关于错误边界（error boundary)的新观念。

须要注意的是： error boundaries 并不会捕捉下面这些错误。

事件处理器
异步代码
服务端的渲染代码
在 error boundaries 区域内的错误

咱们来举一个小例子，在下面这个 componentDIdCatch(error,info) 里的类会变成一个 error boundary：

而后咱们像使用普通组件那样使用它：

componentDidCatch() 方法像 JS 的 catch{} 模块同样工做，可是对于组件，只有 class 类型的组件(class component )能够成为一个 error boundaries 。

实际上，大多数状况下咱们能够在整个程序中定义一个 error boundary 组件，以后就能够一直使用它了！

5、iframe 异常

对于 iframe 的异常捕获，咱们还得借力 window.onerror：

一个简单的例子可能以下：

6、Script error

通常状况，若是出现 Script error 这样的错误，基本上能够肯定是出现了跨域问题。这时候，是不会有其余太多辅助信息的，可是解决思路无非以下：

跨源资源共享机制( CORS )：咱们为 script 标签添加 crossOrigin 属性。

或者动态去添加 js 脚本：

特别注意，服务器端须要设置：Access-Control-Allow-Origin
此外，咱们也能够试试这个-解决 Script Error 的另类思路：

简单解释一下：

改写了 EventTarget 的 addEventListener 方法；

对传入的 listener 进行包装，返回包装过的 listener，对其执行进行 try-catch；

浏览器不会对 try-catch 起来的异常进行跨域拦截，因此 catch 到的时候，是有堆栈信息的；

从新 throw 出来异常的时候，执行的是同域代码，因此 window.onerror 捕获的时候不会丢失堆栈信息；

利用包装 addEventListener，咱们还能够达到「扩展堆栈」的效果

7、崩溃和卡顿

卡顿也就是网页暂时响应比较慢， JS 可能没法及时执行。但崩溃就不同了，网页都崩溃了，JS 都不运行了，还有什么办法能够监控网页的崩溃，并将网页崩溃上报呢？

崩溃和卡顿也是不可忽视的，也许会致使你的用户流失。

一、利用window对象的load和beforeunload事件实现了对网页崩溃的监控。

二、基于如下缘由，咱们可使用service Worker来实现对网页崩溃的监控。

Service Worker 有本身独立的工做线程，与网页区分开，网页崩溃了，Service Worker 通常状况下不会崩溃；
Service Worker 生命周期通常要比网页还要长，能够用来监控网页的状态；
网页能够经过 navigator.serviceWorker.controller.postMessage API 向掌管本身的 SW 发送消息。

8、错误上报

一、经过 Ajax 发送数据
由于 Ajax 请求自己也有可能会发生异常，并且有可能会引起跨域问题，通常状况下更推荐使用动态建立 img 标签的形式进行上报。

二、动态建立 img 标签的形式

收集异常信息量太多，怎么办？实际中，咱们不得不考虑这样一种状况：若是你的网站访问量很大，那么一个必然的错误发送的信息就有不少条，这时候，咱们须要设置采集率，从而减缓服务器的压力:

采集率应该经过实际状况来设定，随机数，或者某些用户特征都是不错的选择。

9、总结

回到咱们开头提出的那个问题，如何优雅的处理异常呢？

可疑区域增长 Try-Catch
全局监控 JS 异常 window.onerror
全局监控静态资源异常 window.addEventListener
捕获没有 Catch 的 Promise 异常：unhandledrejection
VUE errorHandler 和 React componentDidCatch
监控网页崩溃：window 对象的 load 和 beforeunload
跨域 crossOrigin 解决

其实很简单，采用组合方案，分类型的去捕获异常，这样基本 80%-90% 的问题都化于无形。