Error isolation in JavaScript

JavaScript: the error isolation Interface request in JavaScript fails, some data in the interface is missing, and the operation data is not as expected... When our application was launched, we began to face these risks.

Once these problems cause JavaScript errors (such as null pointer exceptions) and are not effectively isolated, it may lead to online problems such as page white screen and interaction failures.

During the preparations for the double 11 shopping holiday, we collected front-end online problems related to the past year. Among the 21 cases collected, half of the problems are related to the reason why the Data Exception trigger page displays an exception.

How to isolate the impact of errors within a certain range is particularly important.

This article will share with you some of the solutions we have tried and the problems we have encountered.

Starting with a null pointer exception

The most common problem caused by data is a null pointer exception.

Var result = a. B. c. d;

Such code is like a mine. Once a is a dynamic data, the problem is imminent.

Encapsulate a get method to obtain the value. If the data does not exist, undefined is returned, which can be quickly avoided.

Var result = get (a, 'B. c. d '); but just as we expect everyone to make judgments before taking the values, there is no way to ensure that everyone is using the values. If (a & a. B & a. B. c) {var result = a. B. c. d ;}

Therefore, we have the following solutions:

Asynchronous Data Verification

The idea of asynchronous data verification is to perform schema verification once after data is obtained and used to detect exceptions such as missing and incorrect data types.

Corresponding to this solution, we encapsulate the fetch-checker Note 1 component on the basis of fetch.

Fetch-checker forces the user to provide the schema corresponding to the data while requesting the data:

let schema = {    "rule": {      "type": "string",    },    "banner": {      "type": "object",      "required": true,      "default": {        "url": "https://item.taobao.com/item.htm?id=527331762117"      }    }};

This schema must be described as follows:

Type of each field

Whether the field is required

If the required field is missing, do you need to base the data?

After obtaining the data, the fetch-checker first checks the data. If necessary, it fills in the missing data and then returns it to the caller. In this way, the data obtained by the user must meet the expectation.

However, this solution faces the following challenges:

Make sure that the caller provides a complete schema description. If you do not want to write a schema, you can provide a rough schema description to pass the verification.

How to streamline the schema. That is, it does not have a big impact on the bundle size and can meet the verification function.

Code compilation

Inspired by babel, this solution converts NPE hidden code into equivalent security code during compilation. As follows:

var a = {};// inputvar result = a.b.c;// outputvar result = (_object2 = (_object3 = a) == null ? null : _object3.b) == null ? null : _object2.c;

When a is a null object, the compiled code returns null, avoiding code errors and blocking subsequent processes.

In babel-plugin-safe-member-expression Note 2, we made the above attempts. Currently, you can enable this function with enableSafeMemberExpression in the cake project.

This solution is less cost-effective than access, and developers do not need to adjust the existing code, but there are also challenges:

Problems in the development phase are not easy to expose, but errors should be clearly reported without any feedback. The ideal status is: expose as many problems as possible during the development and debugging phase, and minimize errors when running online.

How to define the hidden danger code. Currently, all a. B call methods are compiled according to the above scheme. Although no problems have been found during the test, it is safer to only handle hidden code.

Static Verification

Static verification tools represented by flow can detect NPE risks to a certain extent. Type res = {data? : Object} let name = res. data. name; // property 'name'. Propery cannot be accessed on possibly undefined value

As described in the Code above, the user must first determine whether his data can be null. when data is allowed to be null, it is detected by flow. A name similar to this will be called and an error will be detected.

However, it is also difficult to ensure that developers describe all types of services through static verification.

The preceding section describes error isolation in JavaScript. For more information, see the PHP Chinese website (www.php1.cn )!