The front-end monitoring

Generally, a complete front-end project needs to include exception monitoring, so we need to notify our development team in the first time when the project is abnormal, and then fix the bugs in time.

Existing programs

  • Fundebug portal
  • Bugsnag portal
  • Betterjs portal
  • Sentry portal

Exception types

From the perspective of the front end, there are two types of exceptions that the front end needs to pay attention to:

Native JS error

Common js native errors, mainly including SyntaxError (SyntaxError), ReferenceError (ReferenceError), TypeError (TypeError) and RangeError (RangeError, often appear in the array, subscript) and so on, which is caused by the front-end code unqualified, In severe cases, a blank screen can occur, such as when rendering a major component in SPA. This kind of exception can be fatal to the line, so we really need to have a monitor to know if there is a syntax error.

Abnormal interface

An interface exception occurs when an interface has a non-2XX response. If our main interface has a network error, our page cannot be loaded. This is also a serious accident, so we need to pay attention to this exception.

Resource loading exception

Failure to load JS, CSS, and images also needs to be reported, especially for key resources. If the loading fails, the entire page may be blank

unhandledrejection

If a promise is used but no promise is handled, and no catch exception is found, this will result in an unhandledrejection exception. This exception cannot be caught by window.onError or window.addeventListener (‘error’). It needs to be caught by window.addeventListener (‘ unHandlerejction ‘)

Exception handling

window.onerror

Js provides a global method of catching exceptions, window.onerror

window.onerror = function(errorMessage, scriptURI, lineNumber, columnNumber, errorObj) {
    
}
Copy the code

You can see that it contains information about the exception, the file in which the exception occurred, the line and line number of the exception, and the exception object (which contains stack information). These details are the main reason why we use window.onError to catch exceptions, which is not possible compared to window.addeventListener.

However, it has several problems. 1. For security reasons, cross-domain exceptions cannot be caught. 2, different browsers support different exception information, exception stack is not unified, even some browsers do not have stack information. 3. The resource loading exception cannot be known.

The first problem can be solved by setting the crossorigin property and js domain name to CORS. TraceKit NPM package can be used to solve the problem that the stack information is not consistent. For some older browsers that do not have stack information, you need to manually bury the code and use a try catch to bury all the functions/methods. here Specifically, with try catch, the code capacity increases, but the performance impact is minimal. Taobao article. The third problem is that since resource loading errors do not bubble, window.onerror cannot be caught at will, so you need to use window.addEventListener to catch exceptions during the capture phase, but you need to prevent repeated reporting with window.onerror.

window.addEventListner

As mentioned above, we want to use window.addeventListener to catch the exception of a resource loading error, but to avoid duplicate reporting with window.onError

window.addEventListener('error', event = > () {/ / avoid and window onerror repeatedly reported js abnormal const target = event. The target | | event. The srcElement; const isElementTarget = target instanceof HTMLScriptElement || target instanceof HTMLLinkElement || target instanceof HTMLImageElement;if(! isElementTarget)return false; / / report resources address const url = target. SRC | | target. The href; console.log(url); },true);
Copy the code

In addition, window.addeventListener can be used to catch promise exceptions

window.addEventListener('unhandlerejection', event => {
    console.log(event.reason)
})
Copy the code

Redefine XMLHttpRequest, Jsonp, Fetch

For interface requests, we can rewrite the request methods, including XMLHttpRequest and Jsonp of Ajax, as well as the Fetch method of JS, and report the request whose response status is not 200, or other front-end and back-end defined some of the response is an exception request. For example, if the code returned by the data in response is not 0, an exception will be reported.

Use third-party solutions

Use a mature third-party library, such as Sentry, which is also a personal recommendation, because in the above way, one is to duplicate the wheel, and the other is that we may still have some exceptions left unprocessed.

The most troublesome part of using third-party libraries is whether your own company has built corresponding platforms, but generally companies have these exception reporting platforms. I have written a webpack plug-in based on Sentry for automatic integration of Sentry, you can refer to it by clicking here. It does two main things: 1. Initialize sentry. 2. If Webpack has sourcemap configured, it will automatically upload sourcemap to Sentry and delete the sourcemap file after uploading.