Analysis of error monitoring principle

Error monitoring

Original address

Preface

As a front end , Even if you are very careful in the development process , Self test sufficient , Under the complex operation of different users, unexpected problems of programmers will inevitably appear , Bring huge losses to the company or individuals .
At this time, a front-end error monitoring system that can report errors in time and help programmers solve errors well is essential .
Next, let's talk about common error occurrence and handling .

This article mainly focuses on the following points ：

1. common JS Wrong type
2. common JS How to handle errors
3. How to report , And the content of the report

problem ：

1. JS、CSS、img Wait for resource loading failure (CDN Or the picture bed hangs , Inadvertently deleted 、 The file name has changed ) How to know in real time ？ Instead of users telling you ？
2. How to report useful error information enables programmers to quickly locate errors and repair ？ Instead of reporting some confusing information ？
3. In today's engineering, there is no need to compress and deface code , How to make good use of SourceMap file , Handling error messages ？
4. How did something go wrong , Don't let users help you reproduce ？ Required model ？ To operate steps ？
5. How to better calculate the distribution of problems ( Model equipment 、 browser 、 Location 、 Bandwidth, etc. ), Choose compatibility tendency autonomously according to data ？
6. …

Common mistakes

1. Script error
   • Grammar mistakes
   • Runtime error
     • Synchronization error
     • Asynchronous error
     • Promise error
2. Network error
   • Resource load error
   • Custom request error

Grammar mistakes

for example , English characters are written into Chinese characters . Generally, it is easy to be found during development .

Grammatical errors cannot be trycatch Handle

try {
    
  const error = 'error';   //  Rounded semicolon 
} catch(e) {
    
  console.log(' I can't perceive mistakes ');
}

Synchronization error

JS When the engine executes the script , Push the task into the event stack in blocks , Poll fetch execution , Each event task has its own context ,
In the current context, any error in the code synchronously executed can be trycatch Capture , Ensure that the subsequent synchronization code is executed .

try {
  error
} catch(e) {
  console.log(e);
}

Asynchronous error

common setTimeout And other methods will create new event tasks and insert them into the event stack , To be implemented later .
therefore trycatch Unable to catch code errors in other contexts .

try {
    
  setTimeout(() => {
    
    error        //  Asynchronous error 
  })
} catch(e) {
    
  console.log(' I can't perceive mistakes ');
}

In order to facilitate the analysis of errors , General use window.onerror Event to listen for errors .
It is better than trycatch The ability to capture error information should be strong .

/** * @param {String} msg  Error description  * @param {String} url  Error file  * @param {Number} row  Line number  * @param {Number} col  Column number  * @param {Object} error  error Error object  */
 window.onerror = function (msg, url, row, col, error) {
    
  console.log(' I know I'm wrong ');
  // return true; //  return  true  When , Exceptions will not be thrown up , The console will not output errors 
};

window.onerror matters needing attention

1. window.onerror You can capture common syntax 、 Sync 、 Asynchronous error and other errors ;
2. window.onerror Unable to capture Promise error 、 Network error ;
3. window.onerror It should be in all JS The script was executed before , To avoid omitting ;
4. window.onerror Easily covered , When dealing with callbacks, you should consider , Someone is also using this event to listen .

Network error

Because the network request is abnormal, it will not bubble , Only in the event capture phase can we get .
We can use window.addEventListener. For example code 、 Pictures are important CDN Resources are hung , It is extremely important to get feedback in time .

window.addEventListener('error', (error) => {
    
  console.log('404  error ');
  console.log(error);
  // return true; //  Interrupt event propagation 
}, true);

For this kind of resource loading error , Enough information can be obtained in the event object , Cooperate with SMS 、 Nail nail, etc. notify the developer at the first time .

window.addEventListener('error', (e) => {
    
  if (e.target !== window) {
     //  Avoid double reporting 
    console.log({
    
    	url: window.location.href, //  Reference resource address 
    	srcUrl: e.target.src, //  Resource loading error address 
    })
  }
}, true);

window.onerror And window.addEventListener

window.addEventListener The benefits of , Not afraid of callbacks being overwritten , You can listen to multiple callback functions , But remember to destroy to avoid memory leaks and errors .
But we can't get window.onerror So much information . Generally only window.addEventListener To monitor resource loading errors .

• Custom error for network request , It is better to report manually .

Promise error

If you are using promise At the end of the day catch Words , that onerror There's nothing we can do .

Promise.reject('promise error');
new Promise((resolve, reject) => {
    
  reject('promise error');
});
new Promise((resolve) => {
    
  resolve();
}).then(() => {
    
  throw 'promise error';
});

You can also use window.onunhandledrejection or window.addEventListener("unhandledrejection") To monitor errors .
Receive one PromiseError object , You can parse reason attribute , It's kind of similar stack.

The specific compatibility processing is TraceKit.js You can see .

Reporting method

1. img Report
2. ajax Report

function report(errInfo) {
    
  new Image().src = 'http://your-api-website?data=' + errInfo;
}

ajax The class library that should be used , Be the same in essentials while differing in minor points .

• Be careful ：img Request has length limit , If the data is too large, you'd better use ajax.post.

Script error

Scripts that reference different domain names , If there is no special treatment , The report is wrong , Generally, browsers are in security consideration , Do not show specific errors but Script error.
For example, others have ulterior motives to quote your online non open source business code , Of course, you don't want him to know the error information in your script .

If you solve the problem of cross domain error reporting of your own scripts ？

• Switch all resources to the unified domain name , But then you lose CDN The advantages of .
• In the script file HTTP response header Set in CORS.

1. Access-Control-Allow-Origin: You-allow-origin;
2. script Add... To the tag crossorigin attribute , for example <script src="http://www.xxx.com/index.js" crossorigin></script>

Response head and crossorigin Value problem

1. crossorigin="anonymous"( Default ),CORS It's not equal to You-allow-origin, You can't take cookie
2. crossorigin="use-credentials" And Access-Control-Allow-Credentials: true ,CORS Cannot be set to *, energy band cookie.
   If CORS It's not equal to You-allow-origin, Browser does not load js.

When you are ready for the resources that free energy can control cors when ,Script error Basically, it can be filtered out , Don't report .

So much has been said , There is also a very important theme , How to analyze the error information I can capture ？

JavaScript Error analysis

One JavaScript Errors usually consist of the following errors

• error message （error message）
• Trace stack (stack trace)

Developers can throw out a JavaScript error ：

• throw new Error(‘Problem description.’)
• throw Error(‘Problem description.’) <-- equivalent to the first one
• throw ‘Problem description.’ <-- bad
• throw null <-- even worse

The second is recommended , The third and fourth browsers cannot generate traceability stacks in the above two ways .

If you can parse the error information in each line of the trace stack , The ranks are cooperating SourceMap Can't you locate each line of specific source code .
The problem is that different browsers are in the above information , There is no general standard format . The difficulty is to solve the compatibility problem .

for example window.onerror Fifth parameter error The object is 2013 Joined in WHATWG Normative .
In the early Safari and IE10 Not yet ,Firefox It's from 14 Version to join Error Object's ,chrome It's also 2013 It was newly added in the year .

The recommendation

1. window.onerror It's capture JS The best way to make mistakes , When there is a legal Error Object and trace stack .
   It can also avoid some mistakes that cannot be disturbed , For example, plug-in errors and cross domain errors with incomplete information .

2. try catch enhance , The error information thrown is relatively complete , Can make up window.onerror Deficiency . But as I said before ,
   try catch Unable to catch asynchronous errors and promise error , And don't use V8 Engine performance optimization .

For example, Tencent BadJS, The following recommendations are try catch The parcel

• setTimeout and setInterval
• Event binding
• ajax callback
• define and require
• Main business entrance

Whether such a fine-grained package is needed , It depends .

SourceMap

For example, there are the following error trace stacks (stack trace)

ReferenceError: thisIsAbug is not defined
    at Object.makeError (http://localhost:7001/public/js/traceKit.min.js:1:9435)
    at http://localhost:7001/public/demo.html:28:12

It can be parsed into a format

[
	{
    
	  "args" : [],
	  "url" : "http://localhost:7001/public/js/traceKit.min.js",
	  "func" : "Object.makeError",
	  "line" : 1,
	  "column" : 9435,
	  "context" : null
	}, 
	{
    
	  "args" : [],
	  "url" : "http://localhost:7001/public/demo.html",
	  "func" : "?",
	  "line" : 28,
	  "column" : 12,
	  "context" : null
	}
]

There are rows and columns and corresponding SourceMap The file can be parsed to obtain source code information .

Analysis results

The processing code is as follows ：

import {
     SourceMapConsumer } from 'source-map';

//  Must be initialized 
SourceMapConsumer.initialize({
    
  'lib/mappings.wasm': 'https://unpkg.com/[email protected]/lib/mappings.wasm',
});

/** *  according to sourceMap File parsing source code  * @param {String} rawSourceMap sourceMap file  * @param {Number} line  Error line in compressed code  * @param {Number} column  Error column in compression code  * @param {Number} offset  Set the number of adjacent rows returned  * @returns {Promise<{context: string, originLine: number | null, source: string | null}>} * context： Source error line and up and down near  offset  That's ok ,originLine： The source code reports an error ,source： Source file name  */
export const sourceMapDeal = async (rawSourceMap, line, column, offset) => {
    
  //  adopt sourceMap The library is converted to sourceMapConsumer object 
  const consumer = await new SourceMapConsumer(rawSourceMap);
  //  Pass in the number of rows and columns to find , Find the source file and the number of rows and columns before compression 
  const sm = consumer.originalPositionFor({
    
    line, //  Number of compressed rows 
    column, //  Number of columns after compression 
  });
  //  List of all source files before compression 
  const {
     sources } = consumer;
  //  According to what we found source, Find the index location in the source file list 
  const smIndex = sources.indexOf(sm.source);
  //  Find the source code in the source code list 
  const smContent = consumer.sourcesContent[smIndex];
  //  Press... On the source code string " End of line marker " Split into array form 
  const rawLines = smContent.split(/\r?\n/g);
  let begin = sm.line - offset;
  const end = sm.line + offset;
  begin = begin <= 0 ? 1 : begin;
  //  Output source line , Because the array index is from 0 Start , Therefore, the number of rows needs -1
  const context = rawLines.slice(begin - 1, end).join('\n');
  //  Remember to destroy 
  consumer.destroy();
  return {
    
    context,
    originLine: sm.line,
    source: sm.source,
  }
};

According to SourceMap File format , You can understand this code well .

At present, the monitoring system is being developed little by little , If it works well , Will open source ...

Reference website

1. mozilla/source-map
2. Front end code exception monitoring practice
3. Front end exception monitoring - BadJS
4. Extreme optimization of script error amount - Let script errors be clear at a glance