Talk about two functions of try and catch in Javascript

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

The control statements in js include if, for, while, try catch, etc., which will change the direction of the program.

Programs manipulate data, and the data that changes with the running of programs, that is, the advancement of control flow, is called data flow.

Obviously, the data flow depends on the control flow, and the data flow analysis in the program analysis also needs to do the control flow analysis first.

For example, this is a piece of code:

const a = 1;
let b;

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

Because a is 1, it will be executed until b = '1111'; This is the control flow, that is, the code that the program finally executes, which can be used to analyze the trend of the program and do some optimization such as dead code deletion.

With the execution of the control flow, b will be assigned to 2222, which is the data flow, that is, the process of changing values, which can be used to analyze the values of variables of a statement.

Program is for different data to do different processing, if the data is wrong, then the processing program will not be able to deal with, will report errors, will interrupt the subsequent control flow. For example, the data is empty, the data format is incorrect, and so on. At this time, we should do error handling through try catch, which is also called exception handling.

We do exception handling for two purposes:

1. Do some bottom-up treatment for the wrong logic.

For example, when there is an error in parameter resolution, assign a default value in catch. After this error handling, there is no need to report it again. In this case, try catch is also part of the logic, which is equivalent to if else.

2. Make a more scene-based description of the reported errors.

Error reporting of JS is thrown by JS engine. For example, if a method of an null object is called, TypeError will be reported, and if an undeclared variable is used, TypeError will be reported

ReferenceError. The specific Error is reported in different scenarios, which has different meanings:

If the object comes from user input, the user input is incorrect, and if the object is obtained from the server, it means that the data returned by the server is incorrect. In different scenarios, the same Error will have more specific meanings, so we will do try catch. Then, a custom error is thrown, which contains the error description of scene information.

Many libraries and frameworks have done a good job in this, and all the reported errors have specific scene information and even solutions, and some are managed by error numbers, which can be queried through errorno. This is the custom handling of errors.

However, many errors reported in business codes have not been dealt with in this way, and the native Error has been reported directly. We will collect some throw to global errors through the exception monitoring platform, and these errors are often relatively original information. Although the error location and stack are brought, the problem should be located by looking at the source code.

For example, I reported an error that an object is empty, but how do I know what object is empty, what reason it will be, how to solve it, and whether there is a number?

If we can make some custom errors in specific scenes after catch for various errors, would it be much better? This third-party library does a good job, while business code rarely pays attention to scenario-based custom errors.

Of course, the user of front-end business code uses the software through the interface, in fact, as long as all kinds of errors are made with 1 prompt on UI. The code of the library is for developers, so it is necessary to describe all kinds of errors in a scenario, and even number the errors and give solutions.

However, I think business code should treat errors like the third-party library code. Instead of reporting meaningless native errors, it should report some custom errors with specific meanings, so it will be much simpler to troubleshoot and solve problems.

However, although scenario-based custom errors can better help troubleshoot problems, it must be based on the fact that you are sure of the errors that may be reported by this code. If the error information reported by yourself is different from the actual error cause, it will increase the difficulty of troubleshooting problems, so it is better to report the original error.

Summarize

The process of program execution is control flow. Affected by control statements, data will be changed in the process of execution. The change of data is called data flow. Control flow and data flow are two aspects that are often analyzed in program analysis.

Errors interrupt the flow of control, and we need to do some processing for errors, via try catch.

Error handling has two purposes:

One is to do some bottom-up treatment, which is equivalent to if else, and there is no need to report errors.

One is to make a scene description of the native JS error, and create an error object with more specific information to throw out.

Many libraries do this very well, and even number errors and give solutions. However, in fact, many business codes only give feedback to users on UI, and do not package the thrown errors in a scenario. This leads to errors collected by the error monitoring platform are relatively original errors, which need to be checked by looking at the source code. If you can do some scenario-based error packaging like the library code, it will be much easier to count and troubleshoot problems, which most Javascript engineers do not do.