JavaScript Code Exception Monitoring

JavaScript Code Exception Monitoring

JavaScript exceptions generally have two aspects: syntax errors and run-time errors. The methods of capturing and processing two kinds of errors are different, which can affect the specific scheme selection. In general, there are two scenarios for handling JS Exceptions: try...catch capture and window.onerror capture. The following two scenarios respectively analyze the merits and demerits of each.

Although syntax errors should have been avoided by using test tools during the development build phase, it is inevitable that mashiqianti will be deployed to the line.

try...catchCapture

This scenario requires the developer to write code that is used in a code snippet that expects an exception to occur, and sends the exception information to the interface when an try...catch exception occurs:

try{//可能发生异常的代码段}catch(e){//将异常信息发送服务端}

try...catchThe advantage is that you can refine to each block of code, and you can customize the error message for statistics.

Specifically to the two JS exceptions mentioned above, try...catch can not catch syntax errors, when encountered a syntax error, the browser will still throw an error Uncaught SyntaxError , but will not be captured, not into the catch code block.

Also, if there is a callback function in the try code block, it will not be captured, for example:

try{var btn = $(‘#btn‘);    btn.on(‘click‘,function(){ //throw error });}catch(e){}

The exception that is thrown in the BTN listener function in the above code cannot be caught by an outer catch, and must be set to another layer:

try{var btn = $(‘#btn‘);    btn.on(‘click‘,function(){ try{ //throw error }catch(e){} });}catch(e){}

In summary, the try...catch deployment of the scenario is complex, and if manual deployment requires a huge amount of effort, it is also related to the developer's ability and experience. If you rely on a compilation tool deployment (such as FIS), then each block of code is try...catch very ugly and prone to unpredictable problems.

window.onerrorCapture

This approach does not require developers to write a large number of code try...catch , by adding onerror to the window to listen to, in the case of JS exception can be caught when the error message, syntax exceptions and run exceptions can be captured. However window.onerror , this listener must be placed in all JS files before it can be guaranteed to capture all the exception information.

window.onerrorFor more information about events, refer to here.

/** * @param {String}  errorMessage   错误信息 * @param {String}  scriptURL      出错文件的URL * @param {Long}    lineNumber     出错代码的行号 * @param {Long} columnNumber 出错代码的列号 * @param {Object} errorObj 错误信息Object */window.onerror = function(errorMessage, scriptURL, lineNumber,columnNumber,errorObj) { // code..}

The implementation of onerror is slightly different for each browser, but the first three parameters are the same, and some low-version browsers do not have the latter two parameters.

The last parameter errorobj the degree of implementation of each browser is not consistent, specifically, refer to here.

is the specific information of an exception captured by OnError:

In summary, the advantages of the window.onerror scheme are reduced developer workload, ease of deployment, and the ability to catch syntax errors and run errors. The disadvantage is that the error message cannot be customized, and errorobj the implementation of each browser is slightly different, resulting in a limited amount of information to be counted.

Cross-domain JS file exception capture

In order to improve Web performance, most of the current Web product architectures have a CDN, deploying resources to different domain names and leveraging the browser's concurrent request mechanism. What information does the OnError listener capture when an exception occurs in a cross-domain js file? Please see:

There is only a little bit of valuable information Script error , no other information, why is it so?

We all know that browsers have same-origin resource limitations, and are not able to cross-domain requests in normal state. The src attribute of script, IMG, and IFRAME tags has no such limitation, which is also the basis of many cross-domain scenarios. However, even if the script tag can request an exotic JS file, the information in this file will not be exposed to the current domain, which is also caused by the browser's security measures.

So is there a way to get exception information for exotic resources?

In fact, it is very simple, it can be said that basically all of the web products for js/css/image and other static resources are set on the service side Access-Control-Allow-Origin: * of the response header, that is, allow cross-domain requests. In this environment, as long as we add a property on the script tag that requests cross-domain resources crossorigin :

<script src="http://static.toutiao.com/test.js" crossorigin></script>

In this case, an exception in an exotic Test.js file can be captured by the current domain's onerror listener to the detailed exception information.

JavaScript Code Exception Monitoring