错误监控

错误采集

代码异常监控的目的是发现已经存在的代码隐患，根据报错信息对线上问题进行定位和修复。如果开发人员要发现线上错误，那么首先需要对线上发生的错误进行采集。

JavaScript提供了try catch函数用于捕获函数异常，被捕获的错误不会影响后续代码的执行，但是需要依赖开发人员手动对可能出现异常的代码块进行包裹。

try{
    document.getElementById('main'.innterText) = 'test';
}catch(error){
    console.error(error);//TypeError:Cannot set properties of null (setting 'innerText')
}

try catch函数只能捕获当前执行的上下文中抛出的错误。如果被包裹的代码块脱离了当前执行的上下文，则try catch函数没有办法捕获错误。

try{
    setTimeout(()=>{
        document.getElementById('main').innerText = 'test';
    },1000)
}catch(error){
    console.error('捕获成功');//不会被执行
}

在实际开发中，开发人员只会针对一些特殊的案例使用try catch函数。如果大量使用try catch函数，那么不仅会增加开发人员的负担，也会降低代码的可读性，因此需要一种对工程低侵入的错误采集方案。如果需要进行全局JavaScript异常监控，就需要用到window.onerror和window.addEventListener（'error'）。

window.onerror是一个全局变量，默认值为null，接受一个函数用于处理错误，可以通过自定义全局的error事件处理函数来自动收集错误信息。

window.onerror = (message,source,lineno,colno,error)=>{
    console.log('报错信息：',message);
    console.log('错误文件地址：',source);
    console.log('错误文件行数：',lineno);
    console.log('错误文件列数：',colno);
    console.log('错武器Error对象的堆栈：',error);
    //返回true，阻止执行默认事件处理函数，控制台不会再默认打印错误信息
    return true;
}
function throwError(){
    throw new Error('错误');
}
throwError();

若该函数返回true，则阻止执行默认事件处理函数，控制台不会再默认打印错误信息。当JavaScript执行发生错误时，window会触发一个ErrorEvent接口的error事件。如果此时window.onerror不为null，就会执行window.onerror。

window.onerror的缺陷在于它没有办法捕获资源加载的错误，以img标签为例。

<img src="./404.png" onerror="console.log('错误')" />

404.png是一个不存在的资源，当浏览器加载时会报错，加载资源的元素标签会触发一个Event接口的error事件，该事件不会在window上“冒泡”，所以此时window.onerror无法捕获到该事件，会默认执行img标签上的onerror函数。

window.addEventListener（'error'）具备window.onerror的多数功能，但它不能通过返回true的形式来阻止默认事件处理函数的执行，可以通过调用e.preventDefault()方法来阻止默认行为。在错误捕获的时机上，它比onerror更早被触发。

window.addEventListener('error',(e)=>{
    const { message, filename,lineno, colno,error} = e;
    console.log('报错信息：',message);
    console.log('错误文件地址：',filename);
    console.log('错误文件行数：',lineno);
    console.log('错误文件列数：',colno);
    console.log('错武器Error对象的堆栈：',error);
});

虽然资源加载的事件不会在window上“冒泡”，但是开发人员可以在事件捕获阶段采集错误，将addEventListener的第三个参数设置为true，即可在事件捕获阶段采集到错误，从而实现对资源加载错误的监听。

<img src="./404.png" />
<script>
    window.addEventListener('error',(e)=>{
        const { target } = e;
        console.log('资源加载失败标签：',target.nodeName);
        console.log('资源地址：',target.src);
    },true);
</script>

开发人员在使用window.addEventListener（'error'）采集错误时，需要区分JavaScript错误和资源加载错误，可以利用lineno和colno字段实现。当资源加载失败时，回调参数中的两个字段的值为undefined。同时，也可以利用instanceof来判断，JavaScript错误抛出的事件类型为ErrorEvent，资源加载失败抛出的事件类型为Event，ErrorEvent为Event的子类型。优化后的代码如下。

<img src="./404.png" />
<script>
    window.addEventListener('error',(e)=>{
        if(e instanceof ErrorEvent){
            const { message, filename,lineno, colno,error} = e;
            console.log('报错信息：',message);
            console.log('错误文件地址：',filename);
            console.log('错误文件行数：',lineno);
            console.log('错误文件列数：',colno);
            console.log('错武器Error对象的堆栈：',error);
        }else{
            const { target } = e;
            console.log('资源加载失败标签：',target.nodeName);
            console.log('资源地址：',target.src);
        }
    },true);
</script>

JavaScript代码中还存在异步错误，这种错误没办法被上述三种方法捕获，需要使用addEventListener监听unhandledrejection。

new Promise((resolve,reject)=>{
    referenceError
});
window.addEventListener('unhandledrejection',(e)=>{
    console.log('错误信息：',e.reason.message);
    console.log('错误堆栈：',e.reason.stack);
},true);

通过unhandledrejection事件采集到的错误信息不包括抛出错误的文件地址、代码行列，这些信息全部存储在e.reason.stack中。

 ReferenceError: referenceError is not defined
    at parseStack (file:///C:/Users/18307/Desktop/index.html:15:13)
    at new Promise (<anonymous>)
    at file:///C:/Users/18307/Desktop/index.html:14:9

以上述错误堆栈为例，开发人员可以通过正则表达式将结果提取出来，从而得到相应的信息，下面是一个简单的示例。

const parseStack = (stack)=>{
    const results = stack.split('\n');
    const topFile = results[1].trim().split(' ')[2];
    const regResults = topFile.match(/\((.*)?\:(\d+)\:(\d+)\)$/);
    const [,filename,lineno,colno] = regResults;
    return {filename,lineno:+lineno,colno:+colno};
}
window.addEventListener('unhandledrejection',(e)=>{
    console.log('报错信息：'，e.reason.message);
    const {filename,lineno,colno} = parseStack(e.reason.stack);
    console.log('错误文件地址：',filename);
    console.log('错误文件行数：',lineno);
    console.log('错误文件列数：',colno);
    console.log('错误堆栈：',e.reason.stack);

});

部分代码中的JavaScript异常会使用try catch函数进行处理，然后通过console.error打印。由于错误被catch捕获了，所以不会被全局监听的方法捕获。针对这种情况，开发人员可以通过劫持console.error的方式来采集打印的错误信息。

const _consoleError = window.console.error;
window.console.error = (...args)=>{
    //自定义内容部分
    _consoleError.apply(window.console,args);//执行原方法，保证劫持前后运行逻辑一致
}

通过以上措施，开发人员基本能够采集到JavaScript中的错误。在实际开发中，静态资源文件常常被托管到CDN服务器上，而在一般情况下，CDN域名和网站域名是不一致的，出于安全性考虑，浏览器只允许同域的脚本捕获具体错误信息，会对抛出的错误进行脱敏处理，以防止敏感信息泄露，此时捕获错误的JavaScript代码就无法有效获取错误信息。解决以上问题的方法是为跨域脚本添加crossorigin="anonymous"配置，同时CDN服务器需要为HTTP响应报头Access-Control-Allow-Origin配置合理的值，此时就能正常地捕获JavaScript错误。

错误处理

错误可以分为3类：

• JS错误
• Promise异常
• 资源异常

为了方便后续错误的监控、排查定位等工作，开发人员应该为每种错误类型都定义一个固定的数据结构。同步错误和异步错误都属于JavaScript逻辑错误，它们关注的信息在于错误的文件地址和错误堆栈，所以应该具有相同的数据结构。资源加载错误和JavaScript逻辑无关，常常是文件地址错误或者网络状况不佳等原因导致的，所以只需要关注资源的加载标签和地址。两者类型定义如下：

/**JavaScript逻辑错误(包括同步错误、异步错误) */
type JsErrorDetail = {
  type: ErrorType.Error | ErrorType.Promise;
  msg: string; //错误信息
  resourceUrl: string; //资源文件地址
  lineNo: number; //错误行数
  colNo: number; //错误列数
  stack: string; //错误堆栈
}
/**资源错误 */
type ResourceErrorDetail = {
  type: ErrorType.Resource: //错误类型
  tag: string; //记载出错的资源标签，例如img、script和link等
  resourceUrl: string; //资源地址
}

接着需要定义响应的错误处理函数，对它们进行解析。在解析同步错误和异步错误时，都需要考虑抛出的错误未被Error对象包裹的情况，例如，

try{
  throw 1;
}catch(error){
  console.log(error.stack);  //undefined
  console.log(error); //undefined
}

同步错误能够直接从对象中获取错误的文件地址、代码行列位置，但是需要判断stack是否为Error对象。同步错误的解析函数如下。

const parseNormalError = (e)=>{
  const { message, filename, lineno,colno,error} = e;
  const detail = {
    msg: message,
    resourceUrl: filename,
    lineNo: lineno,
    colNo: colno,
    //抛出的错误为Error对象时，可以读取stack信息，否则直接转字符串
    stack: error instanceof Error? error.stack: JSON.stringify(error)
  }
  return detail;
}

开发人员在处理异步错误时，需要先判断e.reason是否为Error对象。如果不是Error对象，就直接将其字符串化。如果是Error对象，那么开发人员可以通过e.reason.message读取错误信息，诸如错误的文件地址、代码行列位置都需要根据stack信息进行解析。parseStack函数的具体实现可以参照上文，异步错误的解析函数如下。

const parseUnhandlerejection = (e)=>{
  const detail = {
    msg: '',
    resourceUrl: '',
    lineNo: -1,
    colNo: -1,
    stack: '',
  };
  if(e.reason instanceof Error){
    const { filename,lineno,colno } = parseStack(e.reason.stack);//从堆栈中解析关键信息
    detail.msg = e.reason.message;
    detail.resourceUrl = filename;
    detail.lineNo = lineno;
    detail.colNo = colno;
    detail.stack = e.reason.stack;
  }else{
    //e.reason可能为非Error对象，此时直接转字符串
    detail.stack = JSON.stringify(e.reason);
  }
  return detail;
}

当开发人员处理资源加载错误时，需要知道加载该资源的标签类型及资源地址。标签类型可以通过target.nodeName获取，但是在获取资源地址时需要经过特殊处理。因为img、video、script等标签是通过src设置资源地址的，link标签则是通过href设置的。除此之外，也可以将标签的其他属性上报，以便排查问题。资源加载错误的解析函数如下。

/**获取dom上所有的属性 */
const getAllAttrs = (dom)=>{
  const attrs = {};
  for(let i = 0;;i++){
    const temp = dom.attributes[i];
    if(!temp){
      return attrs;
    }
    attrs[temp.name] = temp.value;
  }
}
/**解析资源加载错误 */
const parseResourceError = (e)=>{
  const {target} = e;
  const detail = {
    tag: target.nodeName,
    resourceUrl: target.src || target.href,
    attrs: getAllAttrs(target)
  }
  return details;
}

将以上函数封装成一个函数，然后根据错误类型分配对应的处理函数即可。

const parseError=(e)=>{
  if(e instanceof ErrorEvent){ //处理同步错误
    return parseNormalError(e);
  }else if(e instanceof PromiseRejectionEvent){//处理异步错误
    return parseUnhandledrejection(e);
  }else if(e instanceof Event){ //处理资源加载错误
    return pareseResourceError(e);
  }
}

Script error

出于安全原因，浏览器有意隐藏来自不同来源的脚本文件的错误，这是为了比较脚本在无意中将潜在的敏感信息泄露出去，像错误信息、错误堆栈、错误的文件名、行列号都有可能包含敏感信息。出于这个原因，浏览器只监听同源的错误，对于非同源的错误，只能获取一个Script error.的信息，并且没有堆栈，所以监听者只能知道发生了一个错误，但是不知道发生了什么错误。

那么如何去解决呢？

1. 为script添加crossorigin="anonymous"

<script src="http://xxxxxxx" crossorigin="anonymous"></script>

2. 添加跨域头，将浏览器指示任何来源都可以获取这个页面，或者设置为允许访问的域名，CDN一般都支持这个头的设置。

access-control-allow-origin: *

执行时机

由于我们是通过监听的方式去捕获全局的JS错误，那么执行的时机就需要额外的注意，监听只会监听到代码执行后发生的JS错误，这就意味着监听的时机尽可能早，否则如果监听的代码执行较晚，比如错误已经发生了，但是监听代码还没有执行，那么这个错误就会被漏掉，那么怎么解决这个问题呢？这里我们可以使用预收集脚本，提前收集JS错误，

在预收集脚本中通过window.addEventListener('error',handler)来做收集，监听handler是有副作用的，后续完整的监控代码执行后就会把handler给清除掉，或者可以直接复用这个监听，这样就做到了监听尽早执行。

错误排查

开发人员在完成监控的错误采集和处理工作，并对收集到的JavaScript错误信息进行分析后，发现很难进行问题定位。

Uncaught TypeError: Cannot read properties of undefined (reading '2')
    at Module../b.js (<anonymous>:11:132878)
    at e (<anonymous:1:110>)
    at <anonymous>:1:902
    at <anonymous>:1:918

错误信息显示出错的代码位于第11行的第132878列，不仅代码列数十分夸张，变量的名称也可能是混淆的，这是因为生产环境中的代码通常是经过压缩的。

基于对减少请求次数、缩减代码的体积、防止代码泄露及兼容性处理等因素的考量，生产环境的JavaScript文件经过了文件合并、代码压缩及polyfill操作。代码在打包时会删除无意义的换行符和空格，并对变量名进行混淆替换，仅通过上述报错信息，开发人员很难排查错误逻辑。以上问题可以通过Source Map解决。

Source Map是一个源代码映射工具，它可以将压缩后的代码映射回构建前的状态。其原理是通过保存代码处理前后在行、列上的对应关系，形成类似“映射”的结构，生成对应的Source Map文件。如果处理后的代码在运行时抛出异常，就可以借助它快速查找到对应的原始代码。Source Map文件结构示例如下。

{
   version : 3,
   file :  bundle.js ,
   mappings :  AACAA,QAAQC,IADM ,
   sources : [
     webpack://studysourcemap/./test.js 
  ],
   sourcesContent : [
     const value = 123;\nconsole.log(value); 
  ],
   names : [
     console ,
     log 
  ],
   sourceRoot : ""
}

主要包括7个字段，每个字段的作用如下。

• version：用于解析代码映射的Source Map版本。
• sources：代码合并前的所有文件的路径。
• names：代码中的所有变量和方法的名称。
• mappings：记录代码在压缩处理前后的映射位置。
• file：压缩处理后的代码生成的文件名。
• sourcesContent：压缩处理前的源代码。
• sourceRoot：压缩处理前的源文件所在的根路径目录。

因为Source Map文件可以逆向生成处理前的源代码，所以Source Map文件不允许被暴露在生产环境中。为了便于排查问题，开发人员一般会将Source Map文件上传到内网服务器中，只有内部员工才能访问，这样就不会导致代码泄露。