前端代码异常监控实战

前言

之前在对公司的前端代码脚本错误进行排查，试图降低 JS Error 的错误量，结合自己之前的经验对这方面内容进行了实践并总结，下面就此谈谈我对前端代码异常监控的一些见解。

本文大致围绕下面几点展开讨论：

1. JS 处理异常的方式
2. 上报方式
3. 异常监控上报常见问题

JS 异常处理

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

1. 当前代码块将作为一个任务压入任务队列中，JS 线程会不断地从任务队列中提取任务执行。
2. 当任务执行过程中出现异常，且异常没有捕获处理，则会一直沿着调用栈一层层向外抛出，最终终止当前任务的执行。
3. JS 线程会继续从任务队列中提取下一个任务继续执行。
   JavaScript <script> error console.log('永远不会执行');</script><script> console.log('我继续执行')</script>

   1234567

   <script>  error  console.log('永远不会执行');</script><script>  console.log('我继续执行')</script>

在对脚本错误进行上报之前，我们需要对异常进行处理，程序需要先感知到脚本错误的发生，然后再谈异常上报。

脚本错误一般分为两种：语法错误，运行时错误。

下面就谈谈几种异常监控的处理方式：

try-catch 异常处理

try-catch 在我们的代码中经常见到，通过给代码块进行 try-catch 进行包装后，当代码块发生出错时 catch 将能捕捉到错误的信息，页面也将可以继续执行。

但是 try-catch 处理异常的能力有限，只能捕获捉到运行时非异步错误，对于语法错误和异步错误就显得无能为力，捕捉不到。

示例：运行时错误

然而对于语法错误和异步错误就捕捉不到了。

示例：语法错误

一般语法错误在编辑器就会体现出来，常表现的错误信息为： Uncaught SyntaxError: Invalid or unexpected token xxx 这样。但是这种错误会直接抛出异常，常使程序崩溃，一般在编码时候容易观察得到。

示例：异步错误

除非你在 setTimeout 函数中再套上一层 try-catch，否则就无法感知到其错误，但这样代码写起来比较