Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about the capture scheme of the front-end one-stop exception monitoring. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

I. the importance of front-end exception monitoring

Software exception monitoring is often directly related to the quality of the software itself. a complete exception monitoring system can quickly locate the problems that occur in the operation of the software, and can help us quickly locate the source of the exception and improve the quality of the software.

In server development, we often use logs to record request errors and server exception problems, but on the client side, the front-end application is directly deployed and run in the user's browser, if an error occurs, how should it be captured and transmitted to the server? It is very simple for the front-end error log to be sent to the server. It is OK to send a request directly when an exception occurs. Let's mainly discuss the error capture scheme below.

Second, the existing anomaly monitoring scheme

_ window.onerror global exception captures    currently there are two main ways for the front end to catch page exceptions. _ window.onerror captures errors running throughout the page. Its limitation is that cross-domain support needs to be added to cross-domain JavaScript scripts, that is, the modification cost of the server is involved, otherwise the specific stack error information at run time cannot be obtained, but the information of "script error" is not conducive to locating the problem.

_ window.onerror = function (msg, file, row, column, errorObj) {console.log (msg); / / script error. Console.log (file); / / console.log (row); / / 0 console.log (column); / / 0 console.log (errorObj); / / {} setTimeout (function () {/ / send request reporting log information errorReport (e.name, e.message + e.stack);}, 5000);}

Try-catch Runtime solution

Another existing solution of    is try-catch. For a method function, we can define it to catch run-time exceptions in the function, but try-catch can only catch exceptions under the current single scope. In addition, the use of try-catch will bring some performance loss, according to the cycle test, the average loss of 6% to 10% of the performance, but in order to improve the quality and stability of the application, these are acceptable.

Function wrapFunction (fn) {return function () {try {return fn.apply (this, arguments);} catch (e) {console.log (e); _ errorProcess (e); return;}};} / then fn = wrapFunction (fn) can be captured when the code in the fn function goes wrong. / / or the error in the callback function in the asynchronous function can also be caught to var _ setTimeout = setTimeout; setTimeout = function (fn, time) {return _ setTimeout (wrapFunction (fn), time);} / / the module definition function can also be rewritten var _ require = require; require = function (id, deps, factory) {if (typeof (factory)! = 'function' |! factory) {return _ require (id, deps) } else {return _ require (id, deps, wrapFunction (factory));}}

Then we can redefine the commonly used module entry functions, including define,require, so that exceptions in the main scope of the module can be caught through try-catch. In the previous processing method, this method is very effective, and you can directly get the exception and stack information in most error stacks.

Improved one-stop solution

In the era of React development, this method can not be used directly. We know that the components of React are all class, that is, constructors. Here, class and constructors are very similar. Class An except that constructor is class A, other information is similar to function A, and the type obtained by typeof is also the same. But there is no way to load constructor A directly into try-catch because you need to instantiate it with the keyword new and create a new scope.

The problem we need to deal with at this time is to catch errors in the attribute method in React. We should remember that the function in JavaScript has a special attribute prototype. When the function is used as a constructor, the attribute in prototype becomes the instantiated attribute method, and this attribute is also valid for class. Then we can process the contents of the special attribute prototype of class in React and encapsulate the method function in Component.

Function defineReact (Component) {var proto = Component.prototype; for (var key in proto) {if (typeof (protokey) = = 'function') {proto [key] = _ wrapFunction (proto[ key]);}} return Component;}

In this way, errors in internal methods in the React component generated by instantiation can be caught.

Class component extends React.Component {componentDidMount () {var a = {}; console.log (a.b.c);} render () {return hello world;}} export default defineReact (component)

The operation of adding defineReact here can be dealt with in the build packaging tool, which prevents us from making direct changes to the code layer.

Direct error reporting by React is not conducive to location problems.

Directly get stack errors after encapsulation

IV. Summary

In fact, it is not much different from the original way, it is still covered in the prototype property of React components for exception capture through try-catch, which greatly increases the scope of error trapping, which can not only help us quickly locate problems in development, but also catch run-time errors of React online applications.

The above is what the capture scheme of the front-end one-stop exception monitoring shared by the editor is like. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.