The program is executed from top to bottom, and the execution path can be changed by some control statements. Under the influence of control statements, the final execution path of the program is the control flow.

Js control statements include if, for, while, try catch, etc., all of which change the direction of the program.

Programs manipulate data, and data that changes as the program runs, or as the flow of control progresses, is called data flow.

Obviously, the data flow is dependent on the control flow, and the data flow analysis in the program analysis should be done first.

For example, this code:

const a = 1;
let b;

if (a === 1) {
    b = '1111';
} else {
    b = '2222';
}
Copy the code

Since a is 1, it will execute to b = ‘1111’; This is the control flow, which is the code that the program ends up executing. It can be used to analyze the program and do some optimizations like dead code removal.

As the control flow executes, B will be assigned the value 2222. This is the data flow, the process of changing the value, which can be used to analyze the value of a variable in a particular statement.

The program is for different data to do different processing, if there is an error in the data, then the processing program will not be able to process, will report an error, will interrupt the subsequent control flow. For example, the data is empty, the data format is wrong, and so on. This is where you do error handling, or exception handling, through a try catch.

We do exception handling for two purposes:

  1. Do some back-of-the-envelope work on faulty logic.

For example, if a parameter parsing error occurs, assign a default value in catch. There is no need to report it after such error handling. In this case try catch is also part of the logic, if else.

  1. Make a more descriptive description of the reported error.

The JS engine throws TypeError for methods that call a null object, and ReferenceError for undeclared variables. The specific Error is reported in different scenarios, so it has different meanings:

If the object is input from the user, there is an error in the user’s input. If the object is fetched from the server, there is an error in the data returned by the server. In different scenarios, the same Error has a more specific meaning, so we need to do a try catch. It then throws a custom error that contains the description of the error with the scene information.

In this regard, many libraries and frameworks do a better job. The errors reported have specific scene information and even solutions. In addition, some of them are managed through error numbers, and the solutions can be queried through errorNo. This is a custom error handling.

Many errors reported in business code do not do this kind of processing, is directly reported to the native Error. We use the exception monitoring platform to collect errors that are thrown globally, and these errors are often raw information, with error locations and stacks, but with source code to locate the problem.

For example, I reported an object is empty error, but how do I know what the object is empty, what will be the cause, how to solve, whether there is a number.

Wouldn’t it be nice if we could throw scenario-specific custom errors after various catch errors? Third-party libraries do this very well, but business code rarely focuses on scenarioalized custom errors.

Of course, the users of the front-end business code use the software through the interface, which is actually just a few UI prompts for various errors. The library code is intended for developers, so you need to contextually describe errors and even number them and provide solutions.

But I think business code should also treat errors like third-party library code, and instead of reporting native errors that don’t make sense, report custom errors that have a specific meaning so that troubleshooting and resolution are much easier.

But while scenarioalized custom errors can be a better way to troubleshoot problems, they must be based on the certainty that the code is likely to report errors. If the error information reported by yourself is different from the actual error cause, it will increase the difficulty of troubleshooting the problem. It is better to report the original error.

conclusion

The process of program execution is control flow, which is affected by control statements and changes data during execution. Data changes are called data flow. Control flow and data flow are two aspects frequently analyzed in program analysis.

An error interrupts the flow of control, and we’re going to do something with that error, try catch.

Error handling serves two purposes:

One is to do some bottom-feeding, if else, so you don’t have to report any errors.

One is to contextually describe native JS errors, creating an error object with more specific information to throw out.

Many libraries do this very well, and even number errors and provide solutions. But a lot of the business code is actually just feedback to the user on the UI, without scenarioalized packaging of thrown errors. As a result, errors collected by the error monitoring platform are relatively original errors that need to be checked by looking at the source code. It’s much easier to count and debug problems if you can do the same kind of scenarioalized error wrappers as the library code, which most Javascript engineers don’t.