A code fault-tolerant processing method and device based on abstract syntax tree construction

Abstract

The application relates to a code fault-tolerant processing method and device based on an abstract syntax tree during construction, wherein when node traversal and query are performed on AST data after Babel analysis, data nodes requiring asynchronous error processing can be accurately matched, in the construction process, the data nodes to be processed and user-defined error processing logic are correspondingly filled into corresponding nodes in a user-defined error processing template, the node data to be processed is replaced with the filled template data, and a node processing process similar to'matching-filling-replacing' is performed, so that the function of async asynchronous error processing based on construction is achieved. Through the application, the problem of low processing efficiency of the error processing mechanism of the async function in the related art is solved, and the technical effect of improving the error processing efficiency of the async function is achieved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a code fault tolerance processing method and apparatus based on a build-time abstract syntax tree. Background Technology

[0002] With the introduction of async functions in the ES2017 standard and support from modern browsers, async functions have become widely used in web project development. Compared to generator functions, async functions offer advantages such as better semantics and wider applicability. The syntax of async functions is generally simple; the challenge lies in error handling. To handle errors thrown within an async function and prevent interruption of subsequent code execution, the following techniques are used:

[0003] a. Wrap the body of the async function in a try statement, and handle any errors inside with a catch function;

[0004] b. Add a catch method after the promise object following the await statement to handle any errors that may occur earlier;

[0005] c. Use third-party npm package tools (such as await-to-js) to import functions or wrap them with local fault-tolerant functions;

[0006] d. Use webpack-loader or babel plugins for unified processing during the build process.

[0007] The above a to c have the following defects:

[0008] 1. During development, appropriate handling solutions need to be integrated. This requires well-established pre-development conventions and standards, as well as a high level of awareness and code integrity among developers regarding async function error handling. Currently, there are no static code analysis plugins to determine whether error handling has been implemented; issues can only be detected after the code is run online, making the actual outcome unpredictable.

[0009] 2. For existing historical projects, the manual code review and subsequent addition mechanism is inefficient and has a high probability of causing problems again. For example, in later iterations, newly added code logic may not be included in the previous error handling scope again.

[0010] The above d has the following defects:

[0011] 1. Loaders are module source code transformation tools based on the webpack build tool. Since they are only applicable to projects that use webpack as the bundling and building tool, other build tools (such as rollup and vitejs) do not have loader-related configuration interfaces. Therefore, loader processing solutions have certain limitations in technology selection.

[0012] 2. Most existing Babel plugins provided by the community for handling errors within `async` statements are based on an Abstract Syntax Tree (AST) traversal. They first find the `awaitExpressionj` node, then search upwards for parent nodes with the `async` property set to `true`, and perform appropriate processing upon finding a match. However, in real-world projects, to ensure compatibility with target devices and for runtime performance considerations, a preset (`@babel / preset`) `-env` and a runtime plugin (`@babel / plugin-transform-runtime`) are typically configured in the Babel configuration. Since `@babel / preset-env` version 7.7.7+, the `transform-runtime` plugin pre-converts `async` functions into generator functions during the `pre` phase (i.e., asynchronous functions with the `async` keyword are converted into ordinary functions named `_asyncTogenerator`). This change results in the loss of the `async` identifier in nodes, causing the error handling strategy based on `async` property lookup to fail during the actual project build.

[0013] Currently, no effective solution has been proposed to address the low processing efficiency of error handling mechanisms in async functions in related technologies. Summary of the Invention

[0014] The purpose of this application is to address the shortcomings of the prior art by providing a code error handling method and apparatus based on a build-time abstract syntax tree, so as to at least solve the problem of low processing efficiency of the error handling mechanism of async functions in the related art.

[0015] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0016] In a first aspect, embodiments of this application provide a code fault tolerance processing method based on a build-time abstract syntax tree, including:

[0017] Define a try-catch string statement and generate a string template;

[0018] Obtain the AST data after Babel parsing;

[0019] Traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, traverse the specifiers data of the child nodes of the ImportDeclaration node and determine whether the current module variable type is a namespace. If the current module variable type is a namespace, concatenate the namespace name with the value of the pre-configured name attribute to form a string and add it to the cache data. If the current module variable type is not a namespace, add the import module variable name that is the same as the value of the pre-configured name attribute to the cache data.

[0020] For the Function node in the AST data, query the AwaitExpression child nodes downwards to determine whether the AwaitExpression child nodes meet the preset node filtering conditions; for AwaitExpression child nodes that do not meet the node filtering conditions, find the async function node with the async attribute in the parent node of the AwaitExpression child node, and cache the body child node of the async function node; parse the string template into template AST data, and fill the function body content of the async function node into the body child node of the try node in the template AST data, and fill the custom AST data corresponding to the pre-configured customFn attribute into the body child node of the catch node in the template AST data to generate a replacement body child node; replace the body child node of the async function node with the replacement body child node.

[0021] In some embodiments, determining whether an AwaitExpression child node meets preset node filtering conditions includes:

[0022] Query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions.

[0023] Determine whether the expression following the `await` keyword in the `AwaitExpression` child node is a function call. If the expression following the `await` keyword is a function call and satisfies any of the following conditions, then the `AwaitExpression` child node meets the node filtering criteria. Specifically, when the type of the `AwaitExpression` child node is `CallExpression`, the `AwaitExpression` child node will have a `callee` child node:

[0024] The callee child node is of the identifier type and the name of the callee child node exists in the cached data;

[0025] The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

[0026] In some embodiments, it also includes:

[0027] Return an object as data received by other Babel plugins, where the visitor property value of the object is the processed AST data.

[0028] In some embodiments, it also includes:

[0029] Register and configure the plugins under the plugins option in the Babel configuration file in the root directory. The configuration includes the module property, the name property, and / or the customFn property.

[0030] Secondly, embodiments of this application provide a code fault tolerance processing device based on a build-time abstract syntax tree, including:

[0031] Define a unit, used to define try-catch string statements and generate string templates;

[0032] The acquisition unit is used to acquire the AST data after it has been parsed by Babel.

[0033] The first processing unit is used to traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, the unit traverses the specifiers data of the child nodes of the ImportDeclaration node and determines whether the current module variable type is a namespace. If the current module variable type is a namespace, the unit concatenates the namespace name with the value of the pre-configured name attribute to form a string and adds it to the cache data. If the current module variable type is not a namespace, the unit adds the import module variable name that is the same as the value of the pre-configured name attribute to the cache data.

[0034] The second processing unit is used to query the AwaitExpression child nodes downwards from the Function node in the AST data, and determine whether the AwaitExpression child nodes meet the preset node filtering conditions; for AwaitExpression child nodes that do not meet the node filtering conditions, it searches for async function nodes with the async attribute in the parent node of the AwaitExpression child node, and caches the body child node of the async function node; it parses the string template into template AST data, fills the function body content of the async function node into the body child node of the try node in the template AST data, fills the custom AST data corresponding to the pre-configured customFn attribute into the body child node of the catch node in the template AST data, and generates a replacement body child node; it replaces the body child node of the async function node with the replacement body child node.

[0035] In some embodiments, the second processing unit includes:

[0036] The first judgment module is used to query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions.

[0037] The second judgment module is used to determine whether the expression following the await keyword of the AwaitExpression child node is a function call. If the expression following the await keyword is a function call and satisfies any of the following conditions, the AwaitExpression child node is determined to meet the node filtering conditions. Specifically, when the type of the AwaitExpression child node is CallExpression, the AwaitExpression child node will have a callee child node:

[0038] The callee child node is of the identifier type and the name of the callee child node exists in the cached data;

[0039] The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

[0040] In some embodiments, it also includes:

[0041] The return unit is used to return an object as data received by other Babel plugins, wherein the visitor attribute value of the object is the processed AST data.

[0042] In some embodiments, it also includes:

[0043] The configuration unit is used to register and configure the plugins option in the Babel configuration file in the root directory. The configuration includes the module attribute, the name attribute, and / or the customFn attribute.

[0044] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the code fault tolerance processing method based on the build-time abstract syntax tree as described in the first aspect above.

[0045] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the code fault tolerance processing method based on the build-time abstract syntax tree as described in the first aspect above.

[0046] This application adopts the above technical solution. Compared with the prior art, the code fault tolerance processing method based on the build-time abstract syntax tree provided in this application can accurately match the data nodes that need asynchronous error handling when performing node traversal query on the AST data parsed by Babel. During the construction process, the data nodes to be processed and the user-defined error handling logic are filled into the corresponding nodes in the custom error handling template. Then, the data of the node to be processed is replaced with the filled template data. Through a node processing flow similar to `match-fill-replace`, the function of asynchronous error handling based on the build time is achieved. This application, based on the static code processing at each build time, can reduce the problem of subsequent logic execution interruption due to uncaught errors in the online environment, ensuring the robustness of the system. It can reduce the time cost and uncontrollability of manual code review and repair for such problems. At the same time, it can also avoid the practical problems of frequently using try-catch statements to handle asynchronous errors in the development project, resulting in cumbersome coding and poor readability of business code. It solves the problem of low processing efficiency of the error handling mechanism of async functions in related technologies and achieves the technical effect of improving the error handling efficiency of async functions.

[0047] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0048] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0049] Figure 1 This is a structural block diagram of a mobile terminal according to an embodiment of this application;

[0050] Figure 2 This is a flowchart of a code fault tolerance processing method based on a build-time abstract syntax tree according to an embodiment of this application;

[0051] Figure 3 This is a schematic diagram illustrating the workflow of a code fault-tolerant plugin device based on a preferred embodiment of the present application;

[0052] Figure 4 This is a structural block diagram of a code fault-tolerant processing device based on a build-time abstract syntax tree according to an embodiment of this application;

[0053] Figure 5 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0055] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0056] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0057] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0058] This embodiment provides a mobile terminal. Figure 1 This is a structural block diagram of a mobile terminal according to an embodiment of this application. For example... Figure 1 As shown, the mobile terminal includes: a radio frequency (RF) circuit 110, a memory 120, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a wireless fidelity (WiFi) module 170, a processor 180, and a power supply 190, among other components. Those skilled in the art will understand that... Figure 1 The mobile terminal structure shown does not constitute a limitation on the mobile terminal and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0059] The following is combined Figure 1 A detailed introduction to each component of a mobile terminal:

[0060] RF circuit 110 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 180; additionally, it transmits uplink data to the base station. Typically, RF circuitry includes, but is not limited to, antennas, at least one amplifier, transceiver, coupler, low-noise amplifier (LNA), duplexer, etc. Furthermore, RF circuit 110 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.

[0061] The memory 120 can be used to store software programs and modules. The processor 180 executes various functional applications and data processing of the mobile terminal by running the software programs and modules stored in the memory 120. The memory 120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile terminal (such as audio data, phone book, etc.). In addition, the memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0062] The input unit 130 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the mobile terminal. Specifically, the input unit 130 may include a touch panel 131 and other input devices 132. The touch panel 131, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 131), and drive the corresponding connection devices according to a pre-set program. Optionally, the touch panel 131 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 180, and can receive and execute commands sent by the processor 180. In addition, the touch panel 131 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 131, the input unit 130 may also include other input devices 132. Specifically, other input devices 132 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0063] Display unit 140 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile terminal. Display unit 140 may include a display panel 141, optionally configured as a Liquid Crystal Display (LCD), Organic Light-Emitting Diode (OLED), or similar display panel 141. Further, touch panel 131 may cover display panel 141. When touch panel 131 detects a touch operation on or near it, it transmits the information to processor 180 to determine the type of touch event. Subsequently, processor 180 provides corresponding visual output on display panel 141 based on the type of touch event. Although in Figure 1 In this embodiment, the touch panel 131 and the display panel 141 are two separate components to realize the input and output functions of the mobile terminal. However, in some embodiments, the touch panel 131 and the display panel 141 can be integrated to realize the input and output functions of the mobile terminal.

[0064] The mobile terminal may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 141 according to the ambient light level, and the proximity sensor can turn off the display panel 141 and / or backlight when the mobile terminal is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that identify the mobile terminal's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometers, taps), etc. Other sensors that may be configured in the mobile terminal, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0065] The speaker 161 and microphone 162 in the audio circuit 160 provide an audio interface between the user and the mobile terminal. The audio circuit 160 can convert the received audio data into electrical signals and transmit them to the speaker 161, where the speaker 161 converts them into sound signals for output. On the other hand, the microphone 162 converts the collected sound signals into electrical signals, which are received by the audio circuit 160, converted into audio data, and then output to the processor 180 for processing. After processing, the audio data is transmitted via the RF circuit 110 to, for example, another mobile terminal, or the audio data is output to the memory 120 for further processing.

[0066] WiFi is a short-range wireless transmission technology. Mobile terminals using a WiFi module 170 can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 1 WiFi module 170 is shown, but it is understood that it is not a necessary component of a mobile terminal and can be omitted or replaced with other short-range wireless transmission modules, such as Zigbee modules or WAPI modules, as needed without changing the nature of the invention.

[0067] The processor 180 is the control center of the mobile terminal. It connects various parts of the mobile terminal via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 120, and by calling data stored in the memory 120, it performs various functions and processes data of the mobile terminal, thereby providing overall monitoring of the mobile terminal. Optionally, the processor 180 may include one or more processing units; preferably, the processor 180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 180.

[0068] The mobile terminal also includes a power supply 190 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 180 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0069] Although not shown, mobile terminals may also include cameras, Bluetooth modules, etc., which will not be described in detail here.

[0070] In this embodiment, the processor 180 is configured as follows:

[0071] Define a try-catch string statement and generate a string template;

[0072] Obtain the AST data after Babel parsing;

[0073] Traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, traverse the specifiers data of the child nodes of the ImportDeclaration node and determine whether the current module variable type is a namespace. If the current module variable type is a namespace, concatenate the namespace name with the value of the pre-configured name attribute to form a string and add it to the cache data. If the current module variable type is not a namespace, add the import module variable name that is the same as the value of the pre-configured name attribute to the cache data.

[0074] For the Function node in the AST data, query the AwaitExpression child nodes downwards to determine whether the AwaitExpression child nodes meet the preset node filtering conditions; for AwaitExpression child nodes that do not meet the node filtering conditions, find the async function node with the async attribute in the parent node of the AwaitExpression child node, and cache the body child node of the async function node; parse the string template into template AST data, and fill the function body content of the async function node into the body child node of the try node in the template AST data, and fill the custom AST data corresponding to the pre-configured customFn attribute into the body child node of the catch node in the template AST data to generate a replacement body child node; replace the body child node of the async function node with the replacement body child node.

[0075] In some embodiments, the processor 180 is further configured to:

[0076] Query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions.

[0077] Determine whether the expression following the `await` keyword in the `AwaitExpression` child node is a function call. If the expression following the `await` keyword is a function call and satisfies any of the following conditions, then the `AwaitExpression` child node meets the node filtering criteria. Specifically, when the type of the `AwaitExpression` child node is `CallExpression`, the `AwaitExpression` child node will have a `callee` child node:

[0078] The callee child node is of the identifier type and the name of the callee child node exists in the cached data;

[0079] The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

[0080] In some embodiments, the processor 180 is further configured to:

[0081] Return an object as data received by other Babel plugins, where the visitor property value of the object is the processed AST data.

[0082] In some embodiments, the processor 180 is further configured to:

[0083] Register and configure the plugins under the plugins option in the Babel configuration file in the root directory. The configuration includes the module property, the name property, and / or the customFn property.

[0084] This embodiment provides a code fault tolerance method based on build-time abstract syntax tree. Figure 2 This is a flowchart of a code fault tolerance method based on a build-time abstract syntax tree according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0085] Step S201: Define the trycatch string statement and generate a string template;

[0086] Step S202: Obtain the AST data after Babel parsing;

[0087] Step S203: Traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, traverse the specifiers data of the child nodes of the ImportDeclaration node and determine whether the current module variable type is a namespace. If the current module variable type is a namespace, concatenate the name of the namespace with the value of the pre-configured name attribute to form a string and add it to the cache data. If the current module variable type is not a namespace, add the import module variable name that is the same as the value of the pre-configured name attribute to the cache data.

[0088] Step S204: Query the AwaitExpression child nodes downwards from the Function node in the AST data to determine whether the AwaitExpression child nodes meet the preset node filtering conditions. For AwaitExpression child nodes that do not meet the node filtering conditions, find the async function node with the async attribute in the parent node of the AwaitExpression child node, and cache the body child node of the async function node. Parse the string template into template AST data, and fill the function body content of the async function node into the body child node of the try node in the template AST data. Fill the custom AST data corresponding to the pre-configured customFn attribute into the body child node of the catch node in the template AST data to generate a replacement body child node. Replace the body child node of the async function node with the replacement body child node.

[0089] In some embodiments, determining whether an AwaitExpression child node meets preset node filtering conditions includes:

[0090] Query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions.

[0091] Determine whether the expression following the `await` keyword in the `AwaitExpression` child node is a function call. If the expression following the `await` keyword is a function call and satisfies any of the following conditions, then the `AwaitExpression` child node meets the node filtering criteria. Specifically, when the type of the `AwaitExpression` child node is `CallExpression`, the `AwaitExpression` child node will have a `callee` child node:

[0092] The callee child node is of the identifier type and the name of the callee child node exists in the cached data;

[0093] The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

[0094] In some embodiments, the method further includes:

[0095] Return an object as data received by other Babel plugins, where the visitor property value of the object is the processed AST data.

[0096] In some embodiments, the method further includes:

[0097] Register and configure the plugins under the plugins option in the Babel configuration file in the root directory. The configuration includes the module property, the name property, and / or the customFn property.

[0098] The embodiments of this application will be described and illustrated below through preferred embodiments.

[0099] This preferred embodiment provides a code fault tolerance plugin device based on a build-time abstract syntax tree.

[0100] To address the limitations of loader technology selection, this preferred embodiment employs a custom Babel plugin integration approach, making it compatible with different front-end module build and packaging tools (webpack / rollup / viteJS), thereby avoiding the problem of the processing solution failing due to later adjustments to the build tools.

[0101] To address the issue of missing AwaitExpression nodes due to introduced Babel version problems, this preferred embodiment searches downwards through the Function node (which may have higher traversal performance overhead). This allows the corresponding async function node to be found during the traversal, thus avoiding the failure of node search caused by the pre-conversion of async functions by plugin-transform in the pre-stage.

[0102] For the automatic identification and exclusion of various boundary scenarios that do not require processing, this preferred embodiment addresses error handling strategies already added during development, such as try-catch statements, fault-tolerant functions, and promise object catch callbacks, to handle errors within async functions. The plugin automatically identifies and skips these errors during the AST node traversal phase, thus avoiding unnecessary node traversal overhead and processing.

[0103] This preferred embodiment is based on a static code processing scheme during the build process, which improves development efficiency and reduces uncontrollable factors caused by human intervention.

[0104] 1. The solution of using a custom Babel plugin to uniformly process code during the build process can avoid the production failure caused by the inability to automatically check static code during local development and the discovery of subsequent code logic execution interruptions due to unhandled async function errors after deployment.

[0105] 2. Based on the parsing, transformation, and generation of JS module source code during the build process, the uncertainty and later maintenance costs caused by manual inspection and repair can also be reduced.

[0106] 3. The plugin provides users with configurable parameter options. Users can configure the corresponding module address, interface name and import type as dependencies for the plugin to filter data nodes based on the error handling utility functions they have used. Users can also add user-defined error handling strategies (such as error log printing or data reporting to the server) to the final generated code by parsing and appending them during the plugin's source code conversion stage. The method is flexible and scalable.

[0107] In this preferred embodiment, within a front-end project using build tools (webpack / rollup / viteJS, etc.), based on the configuration parameters provided when the user registers this plugin instance, the AST nodes parsed by Babel are traversed and queried to accurately match data nodes requiring asynchronous error handling. During the build process, this plugin instance populates the corresponding nodes in its own defined error handling template with the data nodes to be processed and the user-defined error handling logic, and then replaces the data of the nodes to be processed with the populated template data. Through a node processing flow similar to "matching-filling-replacing," the asynchronous error handling functionality based on the build process is achieved.

[0108] By statically processing code during each build, issues such as uncaught errors causing interruptions in subsequent logic execution can be reduced in online environments, ensuring system robustness and minimizing the time and unpredictability associated with manual code review and fixing of such problems. It also avoids the cumbersome coding and reduced readability of business logic caused by frequently using try-catch statements to handle asynchronous errors during development.

[0109] The configurable parameter interface during registration in this preferred embodiment allows users to provide more accurate node matching conditions and extend custom error handling logic for plugins.

[0110] 1. This example plugin already has the ability to recognize nodes processed using native JavaScript syntax and APIs. Users can further configure the plugin to recognize nodes that have handled asynchronous errors by importing and wrapping custom utility functions through the `module` and `name` attributes in the configuration parameters. The configurable node recognition conditions allow the plugin to more accurately locate the data nodes that need processing based on the actual project situation, avoiding unnecessary duplicate processing of nodes that leads to low data parsing and transformation efficiency and consequently, performance issues in the build process.

[0111] 2. The `customFn` attribute in the configuration parameters provides an interface for custom error handling business requirements. Users can configure relevant business logic through this attribute to implement business functions such as error log reporting. When the plugin matches a data node that needs to be processed, it will parse the relevant business logic code into an AST node and populate it into the `catch` node of the aforementioned error handling template. The configurability of the error handling logic and its build-time population can reduce the cost of modifications caused by later strategy adjustments, improving the plugin's scalability and maintainability for business needs.

[0112] The preferred embodiment includes the following:

[0113] I. Plugin Download

[0114] Since this embodiment has been packaged and uploaded to npm (Node.js Package Manager, a Node.js package management tool designed to help JavaScript developers share packaged code modules. npm consists of three independent parts: a website (the main way for developers to find packages, set parameters, and manage the npm user experience), a registry, and a command-line tool (CLI)), it can be downloaded via the npm command-line tool by executing `npm install babel-plugin-trycatch-wrapper-plus`.

[0115] II. Plugin Registration and Parameter Configuration Process

[0116] 1. In the Babel (JavaScript compiler, which is mainly responsible for parsing, transforming and outputting JavaScript source code) configuration file (usually named .babelrc or bablel.config.js) in the project root directory, perform the relevant registration and configuration work under the plugins option.

[0117] 2. During development, some developers find that frequently using try-catch statements to handle asynchronous errors is cumbersome and reduces the readability of business code. Therefore, they import utility functions from other modules (including locally defined modules or modules downloaded via npm, such as "await-to-js"). These functions typically encapsulate try-catch statements internally to uniformly capture errors in async / await. By wrapping await statements with these functions, asynchronous errors are handled. To avoid unnecessary reprocessing of nodes already handled by this method at runtime, the `module` (function module address) and `name` (variable name imported by the function module) properties in the parameter object can be configured during plugin registration. This allows caching of module variable names whose module file location matches the `module` property value and whose module variable name matches the `name` property value when iterating through `ImportDeclaration` nodes (import declarations, corresponding to module import statements in the source code, including module variable names and module file locations). When traversing an AwaitExpression node, if a function name call from the cached data appears in the child node data, it means that the node has been processed by the above method, and the plugin will skip the processing logic for that node.

[0118] 3. For scenarios requiring custom asynchronous error handling logic (such as reporting to the database to collect log records when an error occurs), the specific logic can be organized as a string and passed to the plugin through the `customFn` attribute in the parameter configuration. When processing the `AwaitExpression` node after the above two exclusion filters, the plugin will replace the content of the async function body of the `AwaitExpression` node with the try node in the blank template based on the trycatch statement string template (`try{}catch(e){}`) created internally by the plugin, and replace the user-defined logic corresponding to the `customFn` attribute with the catch node in the blank template. Finally, the current async function body is replaced with the filled template content to achieve the purpose of custom asynchronous error handling.

[0119] 4. In actual projects, if there is no need to use the utility class wrapper functions mentioned in point 2 above or the custom error handling logic mentioned in point 3 above, the corresponding parameter options do not need to be configured when registering the plugin.

[0120] III. Plugin Workflow

[0121] Figure 3 This is a schematic diagram illustrating the workflow of a code fault-tolerant plugin device based on a preferred embodiment of this application, such as... Figure 3 As shown, it specifically includes:

[0122] 1. Create a processing template:

[0123] Define a trycatch string statement (`try{}catch(e){}`) as a replacement template for the subsequently matched aysnc function node.

[0124] 2. Fault-tolerant function name caching:

[0125] The plugin receives the Abstract Syntax Tree (AST) generated by Babel parsing the source code of each JavaScript file. It then traverses the ImportDeclaration nodes (for example, the named import expression `import{to}from`await-to-js` and the default import expression `import to from`await-to-js`, where `to` is the module variable name and `await-to-js` is the module file path). If the user provided corresponding configuration parameters during plugin registration (i.e., the `module` and `name` properties in the configuration parameter object), the plugin will perform the following logic:

[0126] The system checks if the address of the imported module file corresponding to the ImportDeclaration node matches the value of the module attribute in the configuration parameters. If they match, it continues to traverse the data of its child nodes specifiers (a collection of module variable arrays). It uses the isImportNamespaceSpecifier method of @babel / types (a utility library module of Babel that contains methods for constructing, validating, and transforming AST nodes) to determine if the current module variable type is a namespace. If it is, it concatenates the namespace name with the name attribute value in the configuration parameters into a string and adds it to the cache data. Otherwise, it adds the imported module variable name that is the same as the name attribute value in the configuration parameters to the cache data.

[0127] Note: (1) Cache data is a collection of function names of fault-tolerant functions.

[0128] (2) Namespace means that when importing, the variable names of the exported module are not based on the variable names of the exported module. Instead, the module is imported as a whole as a namespace object. The variable names in the module are used as member properties of the namespace object. For example: import * as namespace from "await-to-js", and the to function is called through namespace.to().

[0129] 3. Filter AwaitExpression nodes:

[0130] By querying the child nodes of type AwaitExpression from the Function node, if a node meets any of the following conditions (if there are sub-conditions, all sub-conditions must be met simultaneously), it can be considered that the node does not need to be processed by the plugin again, and the original node data can be returned directly (nodes that do not meet the conditions will continue to be processed in subsequent processes):

[0131] a. Query the parent node upwards and use the `isTryStatement` method of `@babel / types` to determine whether the parent node has a try statement (if it exists, it means that the code corresponding to the AwaitExpression node has been wrapped by try...catch code).

[0132] b. Use the `isCallExpression` method of `@babel / types` to determine whether the `argument` child node of the current node AwaitExpression is a function call expression (i.e., check whether the expression after the `await` keyword in the source code corresponding to this node is a function call; if the type is CallExpression, this node will have a callee child node). If so, and it meets any of the following conditions, it can be considered that no further processing by the plugin is needed:

[0133] (1) Use the `isIdentifier` method of `@babel / types` to determine whether the above callee node type is an identifier and whether the name exists in the fault tolerance function cache data (i.e., the expression after the `await` keyword is a function call whose function name exists in the cache data).

[0134] Note: For example, in the expression await to(), to() is a function call, and the name to exists in the fault-tolerant function name cache data.

[0135] (2) Use the `isMemberExpression` method of `@babel / types` to determine whether the above callee node type is a member expression. The callee node type is MemberExpression and its child node property satisfies the condition that the name is `catch` and the type is Identifier, or the string concatenated by `object.name-property.name` exists in the cache data of the fault tolerance function name (i.e. the difference in function calling method between the import form of the compatible namespace).

[0136] Note: Member expressions typically refer to calling a member method of an object, such as console.log(), which is the log member method of the console object. MemberExpression type nodes have object and property child nodes.

[0137] 4. Template filling and node replacement:

[0138] The AwaitExpression nodes filtered through process 3 above are the node data that need to be further processed using this example plugin. The specific processing flow is as follows:

[0139] a. Search upwards from the AwaitExpression node for nodes with the async attribute in their parent nodes. The found node is the async function node. Locate the body child node of this function node (the content of the async function) and cache it.

[0140] b. Using the `@babel / template` tool, the string template in the template definition process is parsed into AST data (for convenience, this is called the template AST). If the user provides custom error handling logic when registering the plugin, the corresponding parameter configuration data (the `customFn` attribute in the parameter configuration) is also parsed into AST data (for convenience, this is called the custom AST).

[0141] Note: `@babel / template` is a Babel utility class, primarily responsible for parsing string-type JavaScript code into an AST.

[0142] c. Fill the cached node data in a above into the body child node of the try node in the template AST. If there is data in the custom AST, fill it into the body child node of the catch node in the template AST (that is, fill the empty string template `try{}catch(e){}` defined in the plugin into something like `try{async function body node AST}catch(e){custom AST}`).

[0143] d. Replace the body child node data of the async function node queried in a above with the template AST node data filled in in c.

[0144] 5. Return an object (using the processed AST data as the value of the object's visitor property) as data to be received by other Babel plugins.

[0145] The embodiments of this application can achieve the following technical effects:

[0146] This application's embodiments are adaptable to the technical selection of different web project build tools; they filter and handle errors within async functions, ensuring the normal execution of subsequent logic, improving code robustness, and avoiding online issues caused by unhandled errors within async functions; based on automatic processing by the Babel plugin during each build, it reduces the communication costs among team members regarding problem-solving solutions, avoiding the uncontrollable nature of specifications and conventions due to subjective reasons in the actual development process; it saves time costs for code inspection and repair after project iterations, ensuring the consistency and stability of the output after the build; configurable node filtering parameters allow users to freely organize them according to the actual situation of the project, avoiding incomplete node query coverage due to the limitations of the plugin's internal logic; configurable error handling schemes provide necessary interface support for later strategy adjustments, with strong extensibility.

[0147] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0148] This embodiment provides a code fault-tolerant processing device based on a build-time abstract syntax tree. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0149] Figure 4 This is a structural block diagram of a code fault tolerance processing device based on a build-time abstract syntax tree according to an embodiment of this application, such as... Figure 4 As shown, the device includes:

[0150] Definition unit 41 is used to define trycatch string statements and generate string templates;

[0151] Acquisition unit 42 is used to acquire the AST data after Babel parsing;

[0152] The first processing unit 43 is used to traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, then the data of the specifiers child nodes of the ImportDeclaration node is traversed to determine whether the current module variable type is a namespace. If the current module variable type is a namespace, then the name of the namespace and the value of the pre-configured name attribute are concatenated into a string and added to the cache data. If the current module variable type is not a namespace, then the import module variable name that is the same as the value of the pre-configured name attribute is added to the cache data.

[0153] The second processing unit 44 is used to query the AwaitExpression child nodes downwards from the Function node in the AST data, and determine whether the AwaitExpression child nodes meet the preset node filtering conditions; for AwaitExpression child nodes that do not meet the node filtering conditions, it searches for async function nodes with the async attribute in the parent node of the AwaitExpression child node, and caches the body child node of the async function node; it parses the string template into template AST data, fills the function body content of the async function node into the body child node of the try node in the template AST data, fills the custom AST data corresponding to the pre-configured customFn attribute into the body child node of the catch node in the template AST data, and generates a replacement body child node; it replaces the body child node of the async function node with the replacement body child node.

[0154] In some embodiments, the second processing unit 44 includes:

[0155] The first judgment module is used to query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions.

[0156] The second judgment module is used to determine whether the expression following the await keyword of the AwaitExpression child node is a function call. If the expression following the await keyword is a function call and satisfies any of the following conditions, the AwaitExpression child node is determined to meet the node filtering conditions. Specifically, when the type of the AwaitExpression child node is CallExpression, the AwaitExpression child node will have a callee child node:

[0157] The callee child node is of the identifier type and the name of the callee child node exists in the cached data;

[0158] The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

[0159] In some embodiments, the device further includes:

[0160] The return unit is used to return an object as data received by other Babel plugins, wherein the visitor attribute value of the object is the processed AST data.

[0161] In some embodiments, the device further includes:

[0162] The configuration unit is used to register and configure the plugins option in the Babel configuration file in the root directory. The configuration includes the module attribute, the name attribute, and / or the customFn attribute.

[0163] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0164] An embodiment provides a computer device. The code fault tolerance method based on a build-time abstract syntax tree, in conjunction with this application embodiment, can be implemented by a computer device. Figure 5 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application.

[0165] The computer device may include a processor 51 and a memory 52 storing computer program instructions.

[0166] Specifically, the processor 51 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0167] The memory 52 may include a mass storage device for data or instructions. For example, and not limitingly, the memory 52 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 52 may include removable or non-removable (or fixed) media. Where appropriate, the memory 52 may be internal or external to a data processing device. In a particular embodiment, the memory 52 is non-volatile memory. In a particular embodiment, the memory 52 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0168] The memory 52 can be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 51.

[0169] The processor 51 reads and executes computer program instructions stored in the memory 52 to implement any of the code fault tolerance methods based on the construction-time abstract syntax tree in the above embodiments.

[0170] In some embodiments, the computer device may further include a communication interface 53 and a bus 50. For example, Figure 5 As shown, the processor 51, memory 52, and communication interface 53 are connected through bus 50 and complete communication with each other.

[0171] The communication interface 53 is used to enable communication between the various modules, devices, units, and / or equipment in the embodiments of this application. The communication interface 53 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.

[0172] Bus 50 includes hardware, software, or both, that couples components of a computer device together. Bus 50 includes, but is not limited to, at least one of the following: data bus, address bus, control bus, expansion bus, and local bus. For example, and not as a limitation, bus 50 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 50 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0173] Furthermore, in conjunction with the code fault tolerance processing method based on build-time abstract syntax tree in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the code fault tolerance processing methods based on build-time abstract syntax tree in the above embodiments.

[0174] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0175] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A code fault tolerance method based on build-time abstract syntax tree, characterized in that, include: Define a try-catch string statement and generate a string template; Obtain the AST data after Babel parsing; Traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, traverse the specifiers data of the child nodes of the ImportDeclaration node and determine whether the current module variable type is a namespace. If the current module variable type is a namespace, concatenate the namespace name with the value of the pre-configured name attribute to form a string and add it to the cache data. If the current module variable type is not a namespace, add the import module variable name that is the same as the value of the pre-configured name attribute to the cache data. For the Function node in the AST data, query the AwaitExpression child nodes downwards to determine whether the AwaitExpression child nodes meet the preset node filtering conditions; for AwaitExpression child nodes that do not meet the node filtering conditions, find the async function node with the async attribute in the parent node of the AwaitExpression child node, and cache the body child node of the async function node. The string template is parsed into template AST data, and the function body content of the async function node is filled into the body child node of the try node in the template AST data. The custom AST data corresponding to the pre-configured customFn attribute is filled into the body child node of the catch node in the template AST data to generate a replacement body child node. The body child node of the async function node is replaced with the replacement body child node.

2. The method according to claim 1, characterized in that, Determining whether an AwaitExpression child node meets the preset node filtering criteria includes: Query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions. Determine whether the expression following the `await` keyword in the `AwaitExpression` child node is a function call. If the expression following the `await` keyword is a function call and satisfies any of the following conditions, then the `AwaitExpression` child node meets the node filtering criteria. Specifically, when the type of the `AwaitExpression` child node is `CallExpression`, the `AwaitExpression` child node will have a `callee` child node: The callee child node is of the identifier type and the name of the callee child node exists in the cached data; The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

3. The method according to claim 1, characterized in that, Also includes: Return an object as data received by other Babel plugins, where the visitor property value of the object is the processed AST data.

4. The method according to claim 1, characterized in that, Also includes: Register and configure the plugins under the plugins option in the Babel configuration file in the root directory. The configuration includes the module property, the name property, and / or the customFn property.

5. A code fault tolerance processing device based on a build-time abstract syntax tree, characterized in that, include: Define a unit, used to define try-catch string statements and generate string templates; The acquisition unit is used to acquire the AST data after it has been parsed by Babel. The first processing unit is used to traverse the ImportDeclaration nodes in the AST data and determine whether the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute. If the address of the import module file corresponding to the ImportDeclaration node is consistent with the value of the pre-configured module attribute, the unit traverses the specifiers data of the child nodes of the ImportDeclaration node and determines whether the current module variable type is a namespace. If the current module variable type is a namespace, the unit concatenates the namespace name with the value of the pre-configured name attribute to form a string and adds it to the cache data. If the current module variable type is not a namespace, the unit adds the import module variable name that is the same as the value of the pre-configured name attribute to the cache data. The second processing unit is used to query the AwaitExpression child nodes of the Function node in the AST data, and determine whether the AwaitExpression child nodes meet the preset node filtering conditions; for AwaitExpression child nodes that do not meet the node filtering conditions, the unit searches for async function nodes with the async attribute in the parent node of the AwaitExpression child node, and caches the body child node of the async function node. The string template is parsed into template AST data, and the function body content of the async function node is filled into the body child node of the try node in the template AST data. The custom AST data corresponding to the pre-configured customFn attribute is filled into the body child node of the catch node in the template AST data to generate a replacement body child node. The body child node of the async function node is replaced with the replacement body child node.

6. The apparatus according to claim 5, characterized in that, The second processing unit includes: The first judgment module is used to query the parent node of the AwaitExpression child node and determine whether the parent node has a try statement. If the parent node has a try statement, then the AwaitExpression child node is determined to meet the node filtering conditions. The second judgment module is used to determine whether the expression following the await keyword of the AwaitExpression child node is a function call. If the expression following the await keyword is a function call and satisfies any of the following conditions, the AwaitExpression child node is determined to meet the node filtering conditions. Specifically, when the type of the AwaitExpression child node is CallExpression, the AwaitExpression child node will have a callee child node: The callee child node is of the identifier type and the name of the callee child node exists in the cached data; The callee child node is of type MemberExpression and its child node property satisfies the condition that the name is catch and the type is Identifier, or exists in the cached data as a string concatenated by object.name-property.name.

7. The apparatus according to claim 5, characterized in that, Also includes: The return unit is used to return an object as data received by other Babel plugins, wherein the visitor attribute value of the object is the processed AST data.

8. The apparatus according to claim 5, characterized in that, Also includes: The configuration unit is used to register and configure the plugins option in the Babel configuration file in the root directory. The configuration includes the module attribute, the name attribute, and / or the customFn attribute.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 4.

Images