Code traversal anomaly detection method and device, equipment and storage medium

Abstract

The invention relates to the technical field of research and development management and the field of financial science and technology, and discloses a code traversal anomaly detection method, which comprises the following steps of: analyzing a Java file in a project source code folder to generate an abstract syntax tree; searching a StatementExtension node of the traversal operation in the syntax tree, and judging whether the name of the StatementExtension node starts from a forEach or a for or not; after the traversal operation is confirmed, father nodes in the syntax tree are analyzed upwards, and a father node list is formed. And further analyzing the father node, checking whether conditional judgment statements are included, and determining whether null judgment operation on the data object exists in the conditional judgment statements. And if the null judgment operation is not found, marking the traversal operation as an exception, and generating a corresponding exception report. According to the method, the dependence on a large number of tests in the development stage can be reduced, traversal anomalies are detected in advance, null pointer anomalies during operation are avoided, and the stability and development efficiency of codes are improved.

Description

Technical Field

[0001] The present invention relates to the fields of R&D management technology and financial technology, and in particular to a code traversal anomaly detection method, device, equipment and storage medium. Background Art

[0002] In the process of financial system development, the financial data structure is complex, involving multi-level business logic and data transfer. In modern software development, a data hierarchical domain model is usually used to divide the data in the financial system into multiple data objects, such as data transmission objects, data access objects, business objects, display layer objects, etc. When data is transferred between these objects, financial developers often use foreach or for loops to perform batch operations on all attributes in the data object in order to improve development efficiency.

[0003] However, in the prior art, this traversal operation has some potential problems, especially when the data object is empty. Since the foreach or for operation on the data object will not report an error at the compile stage, the program may have an exception (such as a null pointer exception) at runtime. Such problems are usually difficult to find at the runtime and can only be captured through a large number of tests. The financial system has extremely high requirements for accuracy and stability, and any program exception will lead to business process interruption or data errors.

[0004] However, the existing technology has the following deficiencies when processing these traversal operations:

[0005] Reliance on a large number of tests: In order to avoid these traversal exceptions, it is usually necessary to invest a lot of testing manpower and time to check potential problems in the code. This not only increases the development cost of financial projects, but also has an adverse impact on the progress of the project.

[0006] Insufficient test coverage: Even with a large number of tests, it is difficult to fully cover all potential problems in traversal operations, especially in complex data structures or special circumstances, abnormal traversal problems may be missed.

[0007] Due to these problems, existing financial systems have certain risks in code traversal operations. Financial institutions need to rely on more efficient and accurate code detection tools to help developers detect these potential traversal anomalies in advance to avoid unforeseen errors in the system during operation. These tools need to use static analysis technology to detect potential anomalies during the code writing stage, reduce the testing burden and improve the stability and security of the system. Summary of the invention

[0008] The main purpose of the present invention is to provide a code traversal anomaly detection method, device, equipment and storage medium, aiming to solve the technical problem that the prior art cannot effectively detect that the data object is empty during the traversal operation, thereby failing to prevent potential anomalies in the traversal operation.

[0009] To achieve the above object, the present invention provides a code traversal anomaly detection method, comprising:

[0010] Get the project source code folder and traverse the project source code folder, filter out the java files, and store them in the java file list;

[0011] Parse each java file in the java file list to generate a corresponding abstract syntax tree;

[0012] Find the StatementExpression node representing the expression operation in each abstract syntax tree, and determine whether the name attribute of the StatementExpression node ends with forEach or starts with for;

[0013] If yes, confirm that the StatementExpression node is a traversal operation node, traverse the corresponding abstract syntax tree upward, obtain all parent nodes of the traversal operation node, and generate a parent node list;

[0014] Traversing the parent node list, determining whether the parent node contains a conditional judgment statement, and checking whether the conditional judgment statement contains a null judgment operation on the data object;

[0015] If the conditional judgment statement does not contain a null operation on the data object, it is confirmed that the corresponding StatementExpression node has a data object traversal exception and an exception report is generated.

[0016] In one embodiment, the corresponding abstract syntax tree is traversed upwards to obtain all parent nodes of the traversal operation node and generate a parent node list, including:

[0017] Marking the location information of the traversal operation node, recording the file name, line number and column number of the traversal operation node, for locating the abnormal code position;

[0018] Recording the association relationship between the traversal operation node and the direct parent node, and establishing a hierarchical relationship of the traversal operation node in the context grammar structure;

[0019] Using the hierarchical relationship, recursively search upward in the corresponding abstract syntax tree for all parent nodes of the traversal operation node, and mark the syntax type of each parent node, where the syntax type is used to identify the conditional judgment statement;

[0020] Each parent node is stored in the parent node list according to the grammatical structure to generate a hierarchical parent node path.

[0021] In one embodiment, traversing the parent node list, determining whether the parent node contains a conditional judgment statement, and checking whether the conditional judgment statement contains a null operation on the data object includes:

[0022] Traversing the parent node list, starting from the first node in the parent node list, and processing each parent node in turn;

[0023] Determine the syntax type of each parent node to identify whether it is a conditional statement, wherein the conditional statement includes an if statement, an else if statement, and a switch statement;

[0024] Analyze the identified conditional statements to check whether the conditional expressions contain a null check for the !=null of the data object in the traversal operation;

[0025] If there is any conditional judgment statement that does not contain a null judgment operation, the corresponding traversal operation node is marked as an abnormal node.

[0026] In one embodiment, an exception report is generated, including:

[0027] Generate an exception report and list the StatementExpression nodes marked as abnormal, the exception report includes the file path, line number and column number of the abnormal node;

[0028] Generate a repair suggestion based on the exception report, the repair suggestion includes adding a code example of a null judgment operation before the exception node! = null;

[0029] Send the exception report and repair suggestions to the developer to inform the developer of the problem that needs to be handled;

[0030] In the development environment, abnormal nodes are highlighted to help developers locate problematic codes.

[0031] When the automatic repair instruction is received, a null check code is inserted before the abnormal node according to the repair suggestion, and the inserted code is marked.

[0032] In one embodiment, a project source code folder is obtained and traversed, java files are screened out, and stored in a java file list, including:

[0033] Extract the project source code folder from the project root directory, recursively traverse the subfolders in the project source code folder, and process each subfolder and the files contained in the subfolder layer by layer;

[0034] During the traversal process, hidden files, non-code files, build folders, and test folders are filtered out based on file extensions, hidden attributes, and code file types in the project;

[0035] Filter source code files with the extension .java, and store each filtered Java file path in the Java file list;

[0036] Use file path identifiers to separate processed file paths from unprocessed file paths, and record the processing status of each file during the traversal process, including whether the file has been processed, the file processing time, and the processing result.

[0037] In one embodiment, each java file in the java file list is parsed to generate a corresponding abstract syntax tree, including:

[0038] Performing lexical analysis on the Java file, reading source code in the Java file line by line, and dividing the source code into lexical units, wherein the lexical units include keywords, identifiers, operators, and separators;

[0039] Based on the lexical unit, a syntax analyzer is used to parse the source code in the Java file in sequence, and corresponding syntax nodes are generated according to the syntax structure of the Java language;

[0040] An abstract syntax tree corresponding to the Java file is constructed based on the syntax nodes, wherein the abstract syntax tree is composed of a plurality of syntax nodes, and each syntax node represents a syntax structure element in the Java file.

[0041] In one embodiment, lexical analysis is performed on the Java file, and source code in the Java file is read line by line, including:

[0042] The Java files are grouped based on the size and historical processing time of the Java files in the Java file list, and each group of Java files is assigned to an independent thread for processing;

[0043] Assign processing priority to each Java file based on its importance and modification time;

[0044] The allocated independent threads read the source codes of the Java files in the group line by line according to the processing priority.

[0045] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a code traversal anomaly detection device, which includes a memory, a processor, and a code traversal anomaly detection program stored in the memory and executable on the processor, and the code traversal anomaly detection program, when executed by the processor, implements the steps of the code traversal anomaly detection method as described above.

[0046] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer storage medium, on which a code traversal anomaly detection program is stored, and when the code traversal anomaly detection program is executed by a processor, the steps of the code traversal anomaly detection method as described above are implemented.

[0047] Beneficial effects: The present invention relates to a code traversal anomaly detection method, which generates an abstract syntax tree by parsing the Java files in the project source code folder. The StatementExpression node of the traversal operation is searched in the syntax tree, and it is determined whether its name starts with forEach or for. After the traversal operation is confirmed, the parent nodes in the syntax tree are analyzed upward to form a parent node list. The parent node is further analyzed to check whether it contains conditional judgment statements, and whether there are null judgment operations on data objects in these conditional judgments. If no null judgment operation is found, the traversal operation is marked as abnormal, and a corresponding exception report is generated. The present invention can reduce the dependence on a large number of tests in the development stage, detect traversal anomalies in advance, avoid null pointer exceptions at runtime, and improve the stability of the code and development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0049] Figure 1 A schematic diagram of a flow chart of an embodiment of a code traversal anomaly detection method of the present invention;

[0050] Figure 2 A schematic diagram of functional modules of a preferred embodiment of the device for detecting abnormal code traversal according to the present invention;

[0051] Figure 3 It is a structural schematic diagram of the device hardware operating environment involved in the embodiment of the code traversal anomaly detection device of the present invention. DETAILED DESCRIPTION

[0052] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0053] In the process of financial system development, the financial data structure is complex, involving multi-level business logic and data transfer. In modern software development, a data hierarchical domain model is usually used to divide the data in the financial system into multiple data objects, such as data transmission objects, data access objects, business objects, display layer objects, etc. When data is transferred between these objects, financial developers often use foreach or for loops to perform batch operations on all attributes in the data object in order to improve development efficiency.

[0054] However, in the prior art, this traversal operation has some potential problems, especially when the data object is empty. Since the foreach or for operation on the data object will not report an error at the compile stage, the program may have an exception (such as a null pointer exception) at runtime. Such problems are usually difficult to find at the runtime and can only be captured through a large number of tests. The financial system has extremely high requirements for accuracy and stability, and any program exception will lead to business process interruption or data errors.

[0055] However, the existing technology has the following deficiencies when processing these traversal operations:

[0056] Reliance on a large number of tests: In order to avoid these traversal exceptions, it is usually necessary to invest a lot of testing manpower and time to check potential problems in the code. This not only increases the development cost of financial projects, but also has an adverse impact on the progress of the project.

[0057] Insufficient test coverage: Even with a large number of tests, it is difficult to fully cover all potential problems in traversal operations, especially in complex data structures or special circumstances, abnormal traversal problems may be missed.

[0058] Due to these problems, existing financial systems have certain risks in code traversal operations. Financial institutions need to rely on more efficient and accurate code detection tools to help developers detect these potential traversal anomalies in advance to avoid unforeseen errors in the system during operation. These tools need to use static analysis technology to detect potential anomalies during the code writing stage, reduce the testing burden and improve the stability and security of the system.

[0059] See also Figure 1 , Figure 1 This is a flowchart of an embodiment of a code traversal anomaly detection method provided by the present invention. It should be noted that although a logical sequence is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0060] like Figure 1 As shown, the code traversal anomaly detection method proposed by the present invention includes the following steps:

[0061] S10, obtaining a project source code folder and traversing the project source code folder, filtering out java files, and storing them in a java file list;

[0062] In this embodiment, the project source code folder is extracted from the project root directory specified by the system. The source code folder is a container for the entire project file, usually containing code files, configuration files, resource files, etc. In project development, the source code folder structure is crucial and determines how the files are organized. Pull or load the root folder of the project from the specified path by calling the file system API or version control system (such as Git). Make sure that the path to the folder is correct and that all relevant source code files can be correctly loaded into the system.

[0063] Recursively traverse all files and subfolders in the project source folder. Recursive traversal is a common file processing method, traversing each subfolder layer by layer until all files are traversed. Through a recursive algorithm, traverse each file and subfolder in a folder. You can use system file processing tools (such as Java's Files.walkFileTree()) to read the folder contents layer by layer and record the files.

[0064] After traversing the folder, filter out Java files (i.e. files with a .java extension). This is to ensure that only source code files are processed and non-Java files (such as configuration files, images, and other types of files) are ignored. Filter by file extension and use a filtering mechanism to determine the type of file. You can check the extension of each file through the traversed file list and add .java files to the result list.

[0065] Store the filtered Java file paths in a dedicated list for use in subsequent processing steps. This list is the result of traversal and filtering, ensuring that all Java files are stored in an ordered structure. Create a list or array structure and save the full path of each filtered Java file (including file name, folder path, etc.) to the list. This step can use a collection class (such as ArrayList in Java) to store file paths.

[0066] In one specific implementation, the project source code folder is cloned from a remote Git repository to a local system, and the complete project source code folder is obtained through the git clone command. During the traversal process, a file monitoring mechanism is used to ensure that newly added files or folders in the project folder can be captured during traversal to achieve dynamic traversal. The screening of Java files is not only based on the file extension, but also excludes Java files that do not need to be processed based on the configuration files in the project (such as .ignore files). When storing the Java file path, it is stored in the file system in JSON format for direct use by subsequent automation tools.

[0067] By obtaining the project source code folder in advance and traversing all subfolders, you can ensure that the system can capture all relevant Java files during processing to avoid omissions. At the same time, by filtering Java files and filtering out irrelevant files, the efficiency of subsequent code processing steps is improved. Storing the filtered Java file paths can simplify subsequent operations, ensure the integrity and accuracy of the file list, and effectively improve development efficiency and the accuracy of code management.

[0068] S20, parsing each java file in the java file list to generate a corresponding abstract syntax tree;

[0069] In this embodiment, each Java file selected is parsed, and the file content is decomposed into basic grammatical units that can be analyzed and processed. The parsing process includes lexical analysis and grammatical analysis of the code to understand the grammatical structure of the code in the file. Lexical analysis is responsible for splitting the code into minimum grammatical units such as keywords, variable names, operators, etc.; while grammatical analysis is responsible for checking the combination relationship between these units. When implemented, Java compiler API and open source static code analysis tools (such as Javaparser or ANTLR) can be used to parse Java files. The tool reads the code content as text, processes the code line by line, generates lexical units, and then performs grammatical analysis, checks the grammatical structure and generates an abstract syntax tree.

[0070] An abstract syntax tree (AST) is a tree data structure generated after code parsing, where each node represents a syntax element, such as a variable declaration, method call, control structure, etc. AST is used for subsequent code analysis and operations. It is the output of syntax analysis, showing the hierarchical relationship of the code structure for further analysis and modification. The syntax analyzer builds an abstract syntax tree based on the grammatical rules of the Java language. Each syntax element generates a corresponding node, and the hierarchical structure between the nodes reflects the logical order and scope of the code. AST can be stored in memory or serialized into a file for use in subsequent steps.

[0071] In another specific implementation, the Javaparser library is used to parse the Java file and generate an abstract syntax tree. After the system reads the file content, Javaparser will parse each line of code into lexical units and build an AST according to Java's grammatical rules. The AST structure will be stored as an object for use in subsequent steps. The advantage of Javaparser is that it supports in-depth code parsing and comment analysis, which helps to handle complex code structures.

[0072] By parsing Java files and generating an abstract syntax tree, we can deeply understand the code structure of each file and provide support for subsequent traversal operations and exception detection. The abstract syntax tree accurately expresses the grammatical relationship of the code in a hierarchical form, which can improve the accuracy of code inspection and optimization and reduce the risk of exceptions caused by code errors.

[0073] S30, searching for a StatementExpression node representing an expression operation in each abstract syntax tree, and determining whether a name attribute of the StatementExpression node ends with forEach or begins with for;

[0074] In the present embodiment, a specific node representing a traversal operation is searched in an abstract syntax tree (AST). In Java, a StatementExpression node represents an expression operation in a program, such as variable assignment, method call, etc. By scanning the AST, all these expression operation nodes can be identified, thereby providing a basis for subsequent traversal detection. By traversing each abstract syntax tree (AST), the nodes in the tree are accessed one by one, and the type information of the node is used to identify the node of the StatementExpression type. Syntax analysis tools (such as Javaparser, ANTLR, etc.) provide an API for finding and filtering syntax nodes of a specified type. This process uses a recursive traversal of the syntax tree or a depth-first search (DFS) algorithm to ensure that all possible nodes can be processed.

[0075] After finding the StatementExpression node, you need to further check the name attribute of the node to determine whether it is an operation for traversal. Specifically, determine whether its name ends with forEach (usually used for collection traversal) or starts with for (usually used for for loops). This judgment helps to filter out expressions related to traversal operations and prevent misidentification of other non-traversal expressions. After finding the StatementExpression node, get its name (such as method name or variable name) through the node's attributes. Then, use string matching functions (such as String.endsWith() and String.startsWith()) to check whether the name conforms to the pattern of forEach or for. If the match is successful, mark the node as a traversal operation node for further processing in subsequent steps.

[0076] In another specific implementation, a custom syntax tree traversal algorithm is used to perform a depth-first search (DFS) on the abstract syntax tree of each Java file. At each StatementExpression node, the name attribute is read and regular expression matching is used to detect whether it ends with forEach or begins with for. Successfully matched nodes are added to a list for use in subsequent anomaly detection steps.

[0077] By searching for StatementExpression nodes in the abstract syntax tree and detecting their name attributes, traversal operations in the code can be efficiently identified. The traversal operation identification process is automated, avoiding the tedious work of manually checking traversal operations in the code, reducing the complexity of code maintenance, and improving the accuracy of code detection.

[0078] S40, if yes, confirm that the StatementExpression node is a traversal operation node, traverse the corresponding abstract syntax tree upward, obtain all parent nodes of the traversal operation node, and generate a parent node list;

[0079] In this embodiment, after determining that the name attribute of the StatementExpression node meets the conditions of the traversal operation (such as ending with forEach or starting with for), it is confirmed that the node is a traversal operation node. This means that the code snippet represented by the node may contain a traversal operation of a collection or array. After the name check in the previous step, if the conditions match, the system marks this StatementExpression node as a traversal operation node. This mark makes it clear in subsequent analysis that the node is related to the traversal operation, so as to further check the context information.

[0080] After confirming the traversal operation node, you need to traverse the abstract syntax tree upward from the node to find its parent node. The parent node usually contains the context information of the traversal operation, such as whether the traversal operation is nested in a conditional statement or whether it is associated with other statements. By obtaining these parent nodes, you can better understand the code logic. Use the upward traversal function in the tree structure to access the parent node of the current node layer by layer. You can trace back from the traversal node along the syntax tree to the root node or other logically higher nodes through recursive methods or iterations.

[0081] During the upward traversal, all visited parent nodes are recorded to form a parent node list. This list helps to analyze the context of the traversal operation in detail, such as determining whether the traversal operation is performed under specific conditions. The parent node list stores the traversed node and all parent nodes above it. During the upward traversal, each time a parent node is encountered, the node is added to the list. The generated parent node list is sorted by level, and the higher the level of the parent node, the higher the position. This list will be used for subsequent conditional judgment checks to further analyze the context of the traversal operation.

[0082] In other specific implementations, after confirming the traversed nodes through a custom abstract syntax tree traversal tool, the parent node is obtained in an iterative manner. Each time, the parent node path list is generated by searching from the child node to the upper layer until the root node. In the parent node list, the hierarchical relationship of each node can be marked to help subsequent structured code analysis.

[0083] By traversing the abstract syntax tree upwards and obtaining the parent nodes of the traversal operation nodes, the context information of the code can be effectively captured to help developers understand the logical structure of the traversal operation. The process of generating the parent node list helps to further analyze the safety and abnormal conditions of the traversal operation and avoid potential code errors.

[0084] S50, traversing the parent node list, determining whether the parent node contains a conditional judgment statement, and checking whether the conditional judgment statement contains a null operation for the data object;

[0085] In the present embodiment, the parent node list generated when traversing the syntax tree upwards is processed, and the parent nodes in the list are accessed one by one to analyze their types and structures. By traversing the parent nodes, the logical level at which the traversal operation is located can be identified and its contextual relationship can be understood. Using an iterative or recursive method, each node in the parent node list is accessed in turn, and the type and content of each node are checked to perform subsequent conditional judgment statement analysis. The type of the parent node can be obtained through the attributes of the syntax tree node, and tools such as Javaparser can obtain the type information of each node through its API.

[0086] Conditional statements usually include if statements, else if statements, and switch statements. In this step, the system needs to check whether there are these conditional structures in the parent node to determine whether the traversal operation is controlled by certain specific conditions. If the traversal operation is performed under certain conditions, understanding these conditions can help determine the logical robustness of the code. By checking the type of the parent node, determine whether it belongs to a conditional statement (such as if, else if, switch, etc.). The node type can be obtained by calling the getType() method of the syntax tree traversal tool and matching common conditional statement types. If the parent node is a conditional statement, further analyze its specific content.

[0087] Null check operation is an important step to prevent null pointer exception. In Java, it is usually checked whether the object is null by ! = null. The goal of this step is to check whether there is a null check operation on the data object in the conditional judgment statement, to ensure that the code fully handles the null value situation in the traversal operation to avoid runtime exceptions. After identifying the conditional judgment statement, further parse the conditional expression to check whether it contains a null check operation of ! = null. The child nodes of the conditional expression can be obtained through the syntax tree analysis tool, and the content of these expressions can be analyzed to determine whether there is a null check condition. If a null check operation is found, the conditional statement is marked as safe, otherwise the node is marked as a potential exception.

[0088] In another specific implementation, a custom syntax tree traversal algorithm is used to perform a deep check on the parent node list one by one. When determining the type of each parent node, a regular expression is used to match keywords such as if, else if, or switch. The content of the conditional expression is string analyzed to find out whether there is a null judgment operation (such as != null). If no null judgment operation is found, the traversal node is marked as an abnormal risk.

[0089] By traversing the parent node list and checking whether the conditional judgment statement contains a null operation, the null pointer exception problem in the traversal operation can be effectively prevented. Ensure that the data object is security checked before the traversal operation is performed, reduce the risk of exceptions during code runtime, and improve the robustness and reliability of the code.

[0090] S60: If the conditional judgment statement does not include a null operation on the data object, confirm that a data object traversal exception exists in the corresponding StatementExpression node, and generate an exception report.

[0091] In this embodiment, after checking the conditional judgment statement in the previous step, if the conditional judgment statement does not contain a null judgment operation on the data object (such as != null), then the system considers that the traversal operation has potential risks. The lack of null judgment check may cause a null pointer exception to be thrown when the traversal operation is performed when the data object is empty, affecting the stability of the system. Parse the expression of each conditional judgment statement, especially the conditional expression part, to determine whether it contains != null or other forms of null judgment operations. When no such operation is found, the system marks this conditional judgment as an unsafe traversal, and generates an exception report for the identified abnormal node, which is sent to the developer for reference.

[0092] If the system confirms through analysis that no null check is found in the conditional judgment, the current StatementExpression node will be marked as a traversal exception node. This means that this traversal operation may cause an exception because the data object is empty and should be repaired. The system marks the corresponding traversal operation node (that is, StatementExpression node) as an abnormal node. The information of the node (including file path, line number, column number, etc.) is recorded for subsequent generation of exception reports and repair suggestions. Through this mark, subsequent code processing tools can identify potential problems with the node.

[0093] In one specific implementation, if the conditional statement is checked and it is found that the !=null check operation is missing, the system marks the traversal operation node as abnormal through the Javaparser API. The information of the traversal node, including its file path, code line number and column number, will be stored to generate an exception report. Subsequent automated tools can automatically add null check code before traversing the node based on this abnormal mark.

[0094] By detecting the null operation in the conditional judgment statement, it can effectively identify potential traversal operation exceptions and prevent null pointer exceptions caused by null data objects. After confirming the traversal operation exception node, the system can provide clear repair guidance to help developers improve the robustness of the code and reduce the risk of runtime errors and system crashes.

[0095] The present invention relates to a code traversal anomaly detection method, which generates an abstract syntax tree by parsing Java files in a project source code folder. The StatementExpression node of the traversal operation is searched in the syntax tree, and it is determined whether its name starts with forEach or for. After the traversal operation is confirmed, the parent nodes in the syntax tree are analyzed upward to form a parent node list. The parent node is further analyzed to check whether it contains conditional judgment statements, and it is determined whether there are null judgment operations on data objects in these conditional judgments. If no null judgment operation is found, the traversal operation is marked as abnormal, and a corresponding abnormality report is generated. The present invention can reduce the dependence on a large number of tests in the development stage, detect traversal anomalies in advance, avoid null pointer exceptions at runtime, and improve the stability and development efficiency of the code.

[0096] In one embodiment, in the above S40, traversing the corresponding abstract syntax tree upwards, obtaining all parent nodes of the traversal operation node, and generating a parent node list include:

[0097] S401, marking the location information of the traversal operation node, recording the file name, line number and column number of the traversal operation node, for locating the abnormal code position;

[0098] S402, recording the association relationship between the traversal operation node and the direct parent node, and establishing a hierarchical relationship of the traversal operation node in the context grammar structure;

[0099] S403, using the hierarchical relationship, recursively searching upward in the corresponding abstract syntax tree for all parent nodes of the traversal operation node, and marking the syntax type of each parent node, where the syntax type is used to identify the conditional judgment statement;

[0100] S404, storing each parent node in the parent node list according to the grammatical structure, and generating a hierarchical parent node path.

[0101] In this embodiment, in the abstract syntax tree, the parent nodes are recursively traversed upward from the traversal operation node. Parent nodes represent higher-level structures in the code, and obtaining these nodes can help understand the context of the traversal operation. Recursively traverse the syntax tree, using depth-first search (DFS) or other traversal algorithms to obtain parent nodes one by one. Whenever a parent node is found, the system adds it to the parent node list and continues to traverse upward until the root node.

[0102] In the process of marking the traversal operation nodes, record their specific locations in the source code (file name, line number, column number). This information is crucial for the subsequent generation of exception reports and for developers to locate problematic code. The location information (file name, line number, column number) of each traversal operation node is obtained through a parser (such as Javaparser or ANTLR), and this data is stored as part of the anomaly detection system for easy tracking and repair.

[0103] During the traversal process, the association between the traversal operation node and its direct parent node is recorded. This hierarchical relationship helps understand the location of the traversal operation in the code structure and its related context, such as whether it is nested in a conditional statement or a loop statement. During the upward traversal process, the system associates the traversal operation node with its parent node and establishes its hierarchical structure in the code. This hierarchical structure can be stored in a tree data structure and used for further context analysis.

[0104] When recursively searching for parent nodes, you need to mark the syntax type of each parent node. The syntax type can be a conditional statement, method call, loop statement, etc. This information helps to understand whether the traversal operation is performed under certain conditions. Use the parser API or a custom recursive function to call the getType() method of each parent node to obtain the syntax type, and store the syntax type with the node for further analysis.

[0105] All acquired parent nodes are stored in a list according to their hierarchical structure to form a complete parent node path. This path information helps analyze the location of the traversal operation in the entire code structure and its impact. During the traversal process, each parent node is stored in a list and arranged in hierarchical order to form a parent node path from the bottom to the top. This structured storage method makes it easy to query the context information of the traversal operation.

[0106] In one specific implementation, the abstract syntax tree is parsed by Javaparser, and after confirming the traversal node, all parent nodes are recursively traversed upward. Each time a parent node is found, the location information (file name, line number, column number) of the parent node is recorded and its syntax type (such as if statement, for loop, etc.) is marked. All parent nodes are stored in a linked list, arranged in hierarchical order, and finally a parent node path from the traversal node to the root node is formed.

[0107] This embodiment can comprehensively analyze the context information of the traversal operation by traversing the abstract syntax tree upwards and obtaining all parent nodes of the traversal operation node. Marking the location information and syntax type of the traversal operation node and its parent node can not only help developers quickly locate potential abnormal codes, but also effectively understand the hierarchical relationship of the traversal operation, ensuring the security and robustness of the code.

[0108] In one embodiment, the above S50 includes:

[0109] S501, traverse the parent node list, starting from the first node in the parent node list, and process each parent node in turn;

[0110] S502, judging the syntax type of each parent node to identify whether it is a conditional judgment statement, wherein the conditional judgment statement includes an if statement, an else if statement, and a switch statement;

[0111] S503, analyzing the identified conditional judgment statement to check whether the conditional judgment expression contains a null check for !=null of the data object in the traversal operation;

[0112] S504: If any conditional judgment statement does not include a null judgment operation, the corresponding traversal operation node is marked as an abnormal node.

[0113] In this embodiment, starting from the first node in the parent node list, all parent nodes are processed in order. The parent node list saves all the superior nodes of the traversal operation node. By traversing the list, the type and logical structure of each node can be checked in turn, and it is gradually determined whether it is a conditional judgment statement. When implemented, the system will process the parent nodes one by one in the order of the list. Each parent node can be traversed using an iterator or a recursive method, and passed to the subsequent steps for detailed analysis. The type information of each parent node can be obtained through the attributes of the syntax tree node.

[0114] The syntax type of the parent node is judged to confirm whether the node belongs to the type of conditional judgment statement, such as if, else if or switch statement. Conditional judgment statements are usually used to control the execution logic of traversal operations. Identifying these statements is an important prerequisite for subsequent empty checks. The system will identify whether it is a conditional judgment statement by checking the type information of each parent node. Parser tools usually provide an API for obtaining node types (such as getType()), and their syntax types can be determined by matching keywords (such as if, switch).

[0115] Once a conditional statement is identified, the system will further analyze the content of the conditional expression to check whether there is a null check operation on the data object (i.e. !=null). Null check is an important operation to prevent null pointer exceptions. By confirming the existence of this operation, it can ensure that the traversal operation is performed under safe conditions. In the identified conditional statement, the system will check the content of the conditional expression. You can use the expression parsing tool to obtain the child nodes of the conditional judgment and match the expression with !=null. If a null check is found, the system will consider the traversal operation to be safe.

[0116] If no empty check is found for the data object in the conditional statement, the system will consider that there is a potential exception in the traversal operation and mark the corresponding traversal operation node as an abnormal node. This means that when the code is executed, there may be a runtime error caused by the data object being empty. If the system does not find any empty check operation after traversing all the child nodes of the conditional statement, the current traversal operation node is marked as abnormal. This marking information is usually stored and used to generate an exception report later to remind developers to fix code problems.

[0117] In one specific implementation, the abstract syntax tree is parsed by Javaparser, and when traversing the parent node list, the type of the parent node is checked one by one to identify if, else if or switch statements. The content of the conditional judgment statement is analyzed to find whether it contains a null judgment operation of !=null. If the null judgment condition is not found, the traversal operation node is marked as abnormal, and its position information is stored for subsequent generation of an abnormal report.

[0118] By traversing the parent node list, this embodiment can identify the logical context of the traversal operation and detect whether the conditional judgment statement contains a null check for the data object. This helps to detect potential traversal exceptions in advance and avoid null pointer exceptions during runtime. By automatically marking abnormal nodes, the system provides developers with a clear repair path, effectively improving the robustness of the code and development efficiency.

[0119] In one embodiment, in the above S60, generating an exception report includes:

[0120] S701, generating an exception report and listing StatementExpression nodes marked as abnormal, wherein the exception report includes the file path, line number and column number of the abnormal node;

[0121] S702, generating a repair suggestion based on the exception report, the repair suggestion including adding a code example of a null judgment operation before the abnormal node! = null;

[0122] S703, sending the exception report and repair suggestions to the developer, notifying the developer of the problem that needs to be handled;

[0123] S704, highlighting abnormal nodes in the development environment to help developers locate problematic codes;

[0124] S705: When receiving the automatic repair instruction, insert a null check code before the abnormal node according to the repair suggestion, and mark the inserted code.

[0125] In this embodiment, after detecting that there is a data object traversal exception in the StatementExpression node, a detailed exception report is generated, listing all traversal nodes marked as exceptions. The report contains the specific location information of the abnormal node, such as the file path, line number and column number, to help developers accurately locate the problem code. The system obtains the location information of the abnormal node through a static analysis tool (such as Javaparser or ANTLR). The location information includes the path where the code file is located and the specific line number and column number of the abnormal node. This information is formatted as an exception report and stored as a visualization file or log entry for subsequent use by developers.

[0126] Generate repair suggestions based on the exception report and provide them to developers. It is recommended to add a null check operation of !=null before the abnormal traversal node to ensure that the code safely handles null objects during traversal. The repair suggestion will also include specific code examples to guide developers on how to modify the code. The system automatically generates repair suggestions by analyzing the context of the abnormal node. The core of the suggestion is to ensure the safety of the traversal operation through null checks. Specific code examples can be such as if(object!=null){}, placed before the traversal operation to ensure that the data object is verified before traversal.

[0127] After generating exception reports and repair suggestions, the system pushes this information to relevant developers via email or developer tools to remind them to fix these exceptions. This notification method can be implemented through an integrated development environment (IDE) or a project management tool such as JIRA. Reports can be sent to developers through the system's notification module. Implementation methods include sending reports through the email system or integrating reports directly into code review tools to help developers quickly receive issues and suggestions.

[0128] In the development environment, abnormal nodes are highlighted so that developers can quickly identify problems when reviewing the code. This step is to provide visual cues in the IDE to make the problem code visible and easy to fix. The system integrates with the developer's IDE (such as Eclipse, IntelliJ IDEA) to mark abnormal code lines through the highlight function. The system locates and highlights related code snippets based on the location information of the abnormal node.

[0129] If the developer selects the automatic repair function, the system will automatically insert null check code (!=null) in the code according to the repair suggestion to ensure safety check before traversal operation. At the same time, the system will mark the inserted code so that the developer can track the repair content. After receiving the automatic repair instruction, the system automatically edits the source code and inserts the !=null check operation before the abnormal traversal node. After the insertion is completed, the system will mark the line number and modification record of the repair code to facilitate version control and subsequent code review.

[0130] In one specific implementation, after detecting a traversal exception, the system generates a detailed exception report including the file path, line number, and column number, and sends it to the developer through a plug-in for an integrated development environment (such as IntelliJ IDEA). The report also provides repair suggestions for null operations, and the developer can manually add !=null checks in the code. In the development environment, the abnormal code line is automatically highlighted, and the developer can click the highlighted line to view and fix the problem.

[0131] This embodiment generates exception reports and repair suggestions, and the system helps developers quickly locate and repair traversal exceptions, reducing runtime errors caused by null pointer exceptions. By highlighting the exception code and automatically inserting the repair code, the workload of developers is greatly reduced, greatly improving the robustness of the code and development efficiency.

[0132] In one embodiment, the above S10 includes:

[0133] S101, extracting a project source code folder from the project root directory, recursively traversing the subfolders in the project source code folder, and processing each subfolder and the files contained in the subfolder layer by layer;

[0134] S102, during the traversal process, filtering out hidden files, non-code files, build folders, and test folders according to file extensions, hidden attributes, and code file types in the project;

[0135] S103, filtering source code files with a .java extension, and storing each filtered Java file path in a Java file list;

[0136] S104, using the file path identifier, separates the processed file path from the unprocessed file path, and records the processing status of each file during the traversal process, including whether the file has been processed, the file processing time and the processing result.

[0137] In this embodiment, the source code folder of the entire project is extracted from the project root directory, and then the folder and its contained subfolders are recursively traversed. Recursive traversal is a common file system operation that traverses each level in the folder and processes files and subfolders layer by layer to ensure that all files are accessed. Starting from the root directory, a recursive algorithm is used to traverse all subfolders through the file system API (such as Java's File class). Whenever a subfolder is encountered, the system enters the folder and continues to process the files in it until all levels are traversed.

[0138] While traversing the folder, the system will filter the files and filter out the files that do not need to be processed (such as hidden files, non-code files, build files, and test files) based on conditions such as file extensions and hidden attributes. The purpose is to improve processing efficiency and ensure that only source code files are processed. By checking the attributes of the file (such as file name, extension) and folder name, the system will exclude files or folders that do not meet the conditions. For file extensions and hidden attributes, you can use the isHidden() and getName().endsWith() methods provided by the API for filtering.

[0139] Filter out Java files (with the extension .java) from all files and store the paths of these files in a list for subsequent operations (such as code parsing). Each time a Java file that meets the criteria is encountered, the system saves its full path to a list. You can use file.getName().endsWith(".java") to determine the file type and use ArrayList or a similar data structure to save the path.

[0140] To avoid repeated processing of files and ensure efficient traversal, the system uses file path identifiers to distinguish between processed and unprocessed files. The system also records the processing status of each file, including whether it has been processed, the processing time, and the processing results. Two lists can be created to store the processed and unprocessed file paths respectively. When processing each file, the system records its processing status, including the processing time (using the system timestamp) and the result (such as whether it was successfully parsed). These data can be stored in log files or databases for subsequent analysis.

[0141] In one specific implementation, the system clones the project source code folder from the Git repository, recursively traverses each subfolder, and uses Java's FileAPI to filter out hidden files, test files, and build files. The system uses regular expressions to filter out all files with a .java extension and stores their paths in an ArrayList. After processing each file, the system records its processing status, including whether it has been processed, the processing time, and the processing results, and stores this status information in a local log file to avoid subsequent repeated processing.

[0142] This embodiment recursively traverses the project source code folder and filters out Java files, so that the system can efficiently process the source code of large projects and avoid processing irrelevant files and folders. Using file path identifiers to record the status of processed and unprocessed files can avoid repeated operations and improve processing efficiency. At the same time, it accurately records the file processing time and results, which is helpful for subsequent code analysis and project management.

[0143] In one embodiment, the above S20 includes:

[0144] S201, performing lexical analysis on the Java file, reading source code in the Java file line by line, and dividing the source code into lexical units, wherein the lexical units include keywords, identifiers, operators, and separators;

[0145] S202, based on the lexical unit, using a syntax analyzer to parse the source code in the Java file in sequence, and generating corresponding syntax nodes according to the syntax structure of the Java language;

[0146] S203: construct an abstract syntax tree corresponding to the Java file based on the syntax nodes, wherein the abstract syntax tree is composed of a plurality of syntax nodes, and each syntax node represents a syntax structure element in the Java file.

[0147] In the present embodiment, lexical analysis is the first step of parsing source code, which is responsible for segmenting the character sequence in the code into the smallest lexical units (tokens), which represent the basic elements in the code, such as keywords, identifiers, operators and separators. Lexical analysis identifies different types of lexical units by scanning the source code, and builds the basis required for subsequent syntax analysis. The Java file content is read line by line by a lexical analyzer, the code characters are scanned, and they are split into lexical units according to the lexical rules of the Java language. These lexical units can be automatically generated by regular expressions or built-in lexical analysis tools (such as Javaparser or ANTLR). Each lexical unit will be classified as a keyword, an identifier, an operator, etc.

[0148] Syntax analysis is based on the lexical units generated by lexical analysis. According to the grammatical rules of the Java language, these units are combined to generate syntax nodes. Syntax nodes represent the logical structure of the code, such as expressions, control flows, method calls, etc. The system will input the lexical units into the syntax analyzer, and gradually build each node in the syntax tree according to the grammatical rules of Java. The syntax analyzer is responsible for checking whether the combination of these lexical units conforms to the Java syntax, parsing the structure of the code and generating syntax nodes representing these structures (such as expression nodes, statement nodes, etc.).

[0149] The Abstract Syntax Tree (AST) is the final result of syntax analysis. It represents the syntax hierarchy of the code through a tree structure. Each syntax node has its own parent node and child node in the tree, reflecting the structure and logical order of the code. AST is used for further code analysis and manipulation. The syntax nodes generated by the syntax analyzer are organized into a tree structure one by one according to the logical order of the code. Each syntax node will have a corresponding parent node and child node, indicating its hierarchical relationship in the code structure. After construction, the AST can be stored in memory for subsequent analysis.

[0150] In one specific implementation, when parsing a Java file, a Javaparser tool is used to perform lexical analysis on the source code. First, the system reads the Java file line by line, identifies all lexical units, and classifies them into keywords, operators, identifiers, etc. Then, the syntax analysis function of Javaparser is used to generate syntax nodes according to the rules of the Java language. The generated syntax nodes are sequentially organized into an abstract syntax tree (AST) and stored as a tree structure for subsequent processing.

[0151] This embodiment generates an abstract syntax tree through lexical analysis and syntax analysis of Java files, and the system can efficiently understand the grammatical structure of the code. AST provides a logical representation of the code, which can be used for subsequent code optimization, static analysis, and error detection. Through this hierarchical parsing method, the system can capture syntax errors and potential code problems before compilation, thereby improving the reliability and robustness of the code.

[0152] In one embodiment, in the above S201, lexical analysis is performed on the Java file, and source code in the Java file is read line by line, including:

[0153] S2011, grouping the Java files based on the size and historical processing time of the Java files in the Java file list, and assigning each group of Java files to an independent thread for processing;

[0154] S2012, assigns a processing priority to each Java file based on its importance and modification time;

[0155] S2013, the allocated independent thread reads the source code of the Java file in the group line by line according to the processing priority.

[0156] In this embodiment, Java files are grouped to optimize processing by analyzing the size and historical processing time of Java files. The size of the file affects the complexity of processing, while the historical processing time can reflect the time efficiency of the last processing. This step optimizes performance through group processing and reduces the burden of single-thread processing of large or complex files. The system first reads the metadata of the Java file, including the file size and the last processing time. These files are grouped through an algorithm to ensure that the total processing volume of each group of files is balanced. Next, an independent thread is assigned to each group, and multi-threaded parallel processing technology is used to accelerate the lexical analysis of Java files.

[0157] First, the system needs to obtain the basic properties of each Java file, including file size and historical processing time:

[0158] File size: You can directly get the byte size of a file through the system file API (such as File.length() in Java).

[0159] Historical processing time: The historical processing time can refer to the time when the file was last modified or processed. Through the metadata of the file, the system can call File.lastModified() to obtain the last modification time. If the file is managed by a version control system (such as Git), the Git command can be used to obtain the file's submission history.

[0160] The goal of grouping Java files by file size and historical processing time is to balance the processing load of each group while giving priority to important files. Specific strategies can be based on file size, historical processing time and predefined rules:

[0161] File size grouping: divide files into small, medium, and large categories according to their size. You can define different thresholds (e.g., files less than 100KB are small files, 100KB to 1MB are medium files, and files larger than 1MB are large files) so that files of different sizes can be evenly distributed during processing.

[0162] Processing large files consumes more resources and time, so grouping large files separately and assigning them to different threads can prevent a single thread from slowing down the overall efficiency due to processing large files. Small files are processed relatively quickly and can be processed in batches and assigned to multiple threads to improve processing efficiency and resource utilization. By grouping files according to size, each thread is ensured to have a balanced load, preventing a thread from taking up too many resources due to processing large files, which can lead to system performance bottlenecks.

[0163] Historical processing time grouping: The historical processing time of a file affects the priority of the file. The most recently modified files are placed in the priority group, and the files with a longer last modification time are placed in the low priority group. For example, files modified within a week belong to the "high priority group", while files modified more than a month belong to the "low priority group".

[0164] Recently modified files usually represent more active parts of the project, or frequently updated modules. These files may be critical to the overall operation of the system, so they need to be processed and detected first. Files that have not been modified for a long time These files have usually been verified many times and may be less risky. It is reasonable to assign them a lower priority because they have less urgency and importance in the project. By grouping by historical processing time, the latest and most important files that developers care about can be processed first, ensuring that these codes can be quickly detected and fixed at critical moments in the project.

[0165] In the implementation process, the system can group the files by size by traversing the Java file list:

[0166] Small file group: stores files with a size less than 100 KB.

[0167] Medium file group: stores files with sizes between 100KB and 1MB.

[0168] Large file group: stores files larger than 1 MB.

[0169] The files in each group will be evenly distributed to different processing threads. In this way, the system can process a large number of small files at the same time, and can also process large files through independent threads to avoid large files occupying too many resources.

[0170] The system first traverses the metadata or version control information of the file to obtain the historical processing time of each file:

[0171] High priority group: contains files that have been modified recently (such as within 1 week). These files may be the core modules of the project and need to be processed first.

[0172] Medium priority group: contains files with modification time between 1 week and 1 month.

[0173] Low priority group: contains files that have been modified for more than one month.

[0174] After the grouping is completed, the system assigns these files to different processing threads in order of priority to ensure that important files that have been recently modified can be processed first.

[0175] The system can combine file size and historical processing time to group in a more granular manner.

[0176] For example:

[0177] High-priority large file group: files that have been recently modified and are large in size. These files may have a significant impact on the project and are processed first.

[0178] High-priority small file group: files that have been recently modified but are smaller and are processed faster.

[0179] Low-priority large file group: files with a long history but large size, which may not be the focus of the project.

[0180] Low-priority small file group: files with a long history and small size.

[0181] Combining file size and historical processing time to group files not only balances the load of each thread, but also ensures that key modules in the project are processed first. Grouping large files can avoid concentrating resources on a certain thread, and assigning higher priority to recently modified files can improve the stability and maintainability of the project. With this combination, the system can assign different processing strategies based on the characteristics of each file. Large files and high-priority files are processed independently, while small files and low-priority files can be processed in batches. This approach maximizes the system's parallel processing capabilities and avoids processing bottlenecks.

[0182] The processing priority of each Java file depends on its importance in the project (such as the core business module code) and the most recent modification time (the most recently modified files may need to be processed first). In this way, files that have a greater impact on the overall project are processed first to ensure that key codes are checked and processed in a timely manner. The system calculates the processing priority of each file based on the properties of the Java file (such as file location, importance tags, dependencies, etc.) and the last modification time. Important files and recently modified files will be assigned higher priorities to ensure that these files can enter the lexical analysis stage as soon as possible.

[0183] Importance usually reflects the role of a file in a project. For example, the code files of core business logic, key algorithms, or main modules are obviously more important than auxiliary files (such as test files and tool classes). The following methods can be used to determine the importance of a file:

[0184] File path: The location of a file may determine its importance. For example, a file located in the "src / main / " directory may be more important than a file in the "test / " directory.

[0185] Project configuration: Sometimes there are configuration files (such as pom.xml or build.gradle) in the project, which list the dependencies and criticality of certain modules or packages. The system can prioritize the relevant code files based on these configurations.

[0186] Historical modification records: If a file has been modified multiple times or frequently accessed by multiple developers, it can be inferred that the file is of high importance.

[0187] Tags or comments: In large projects, developers may mark certain files as key modules in code comments or project documents. This information can be used as a reference.

[0188] Modification time is another important factor that affects the priority of processing. The most recently modified files are usually more likely to contain potential errors or content that needs to be retested and checked. You can get the modification time of a file in the following ways:

[0189] File system metadata: Get the last modification time of a file through the operating system API (such as Java's File.lastModified()).

[0190] Version control system: When using version control systems such as Git and SVN, you can use these tools to obtain the modification history of files. For example, Git's git log command can provide a file modification record.

[0191] Processing priority can be assigned the following priorities based on the importance and modification time of the file:

[0192] High priority: core business files or recently modified files. For example, files that were last modified within a week or files in the main business logic module.

[0193] Medium priority: functional files or files modified within the last 1-4 weeks, which are of high importance but not the most critical part of the project.

[0194] Low priority: test files, tool files, or files that have not been modified for a long time. These files have little impact on the project.

[0195] By reading the metadata of each Java file and analyzing the file path and modification time, the system can assign a weight to each file. For example, a file with both important file importance and modification time has a high weight and can be marked as a high priority.

[0196] After assigning a separate thread to each group of files, the thread reads the source code of the Java file line by line according to the file priority and starts lexical analysis. By processing line by line, the system can effectively handle large files and avoid memory overflow or long processing time. Each separate thread reads the Java file line by line from the beginning to the end according to the file priority order and converts the code content into lexical units. The system processes the file content through a memory buffer or streaming reading method to ensure that even large files can be parsed efficiently.

[0197] In another specific implementation, Java files are grouped according to their importance tags (such as codes marked as core business modules) and modification histories. The system assigns independent threads to each group, reads the code according to priority, and processes important files first. Each thread reads the file line by line, uses a buffer to store the read data, and performs lexical analysis on the source code to generate a series of lexical units. The size of the file affects its grouping method to ensure load balancing for each thread.

[0198] This embodiment can effectively improve the efficiency of file parsing and avoid the performance bottleneck of single-thread processing by processing Java files in groups based on file size, modification time and importance. Multi-threaded parallel processing ensures that the system can process multiple Java files at the same time. Especially in large-scale projects, this optimization strategy can significantly shorten the time of lexical analysis and overall parsing.

[0199] The present invention also provides a code traversal anomaly detection device, referring to Figure 2 , Figure 2 This is a functional module diagram of a preferred embodiment of a code traversal anomaly detection device of the present invention. The code traversal anomaly detection device comprises:

[0200] The file management and screening module 10 is used to obtain the project source code folder and traverse the project source code folder, screen out the Java files, and store them in the Java file list;

[0201] A code parsing module 20, used to parse each java file in the java file list and generate a corresponding abstract syntax tree;

[0202] A traversal operation identification module 30 is used to search for a StatementExpression node representing an expression operation in each abstract syntax tree, and determine whether a name attribute of the StatementExpression node ends with forEach or begins with for;

[0203] The syntax tree traversal module 40 is used to, if yes, confirm that the StatementExpression node is a traversal operation node, traverse the corresponding abstract syntax tree upwards, obtain all parent nodes of the traversal operation node, and generate a parent node list;

[0204] A parent node analysis module 50 is used to traverse the parent node list, determine whether the parent node contains a conditional judgment statement, and check whether the conditional judgment statement contains a null operation on the data object;

[0205] The exception detection module 60 is used to confirm that a data object traversal exception exists in the corresponding StatementExpression node if the conditional judgment statement does not contain a null operation on the data object.

[0206] The specific implementation of the code traversal anomaly detection device of the present invention is basically the same as the embodiments of the above-mentioned code traversal anomaly detection method, and will not be repeated here.

[0207] The present invention also provides a code traversal anomaly detection device, such as Figure 3 As shown, the code traversal anomaly detection device may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0208] Those skilled in the art will understand that Figure 3 The hardware structure of the code traversal anomaly detection device shown in the figure does not constitute a limitation on the code traversal anomaly detection device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0209] like Figure 3As shown, the memory 1005 as a storage medium may include an operating system, a network communication module, a user interface module, and a code traversal anomaly detection program. The operating system is a program for managing and controlling the code traversal anomaly detection device and software resources, and supports the operation of the network communication module, the user interface module, the code traversal anomaly detection program, and other programs or software; the network communication module is used to manage and control the network interface 1004; the user interface module is used to manage and control the user interface 1003.

[0210] exist Figure 3 In the hardware structure of the code traversal anomaly detection device shown, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the client and communicate data with the client; the processor 1001 can call the code traversal anomaly detection program stored in the memory 1005 and perform the same operation as the code traversal anomaly detection method.

[0211] The specific implementation of the code traversal anomaly detection device of the present invention is basically the same as the above-mentioned embodiments of the code traversal anomaly detection method, and will not be repeated here.

[0212] In addition, an embodiment of the present invention further provides a computer storage medium, on which a code traversal anomaly detection program is stored. When the code traversal anomaly detection program is executed by a processor, the steps of the code traversal anomaly detection method described above are implemented.

[0213] The specific implementation of the computer storage medium of the present invention is basically the same as the embodiments of the above-mentioned code traversal anomaly detection method, and will not be repeated here.

[0214] It should be noted that if software tools or components other than those of our company appear in the embodiments of the present application, they are only used for illustrative purposes and do not represent actual use.

Claims

1. A code traversal anomaly detection method, characterized in that: The following steps are involved: Get the project source code folder and traverse the project source code folder, filter out the java files, and store them in the java file list; Parse each java file in the java file list to generate a corresponding abstract syntax tree; Find the StatementExpression node representing the expression operation in each abstract syntax tree, and determine whether the name attribute of the StatementExpression node ends with forEach or starts with for; If yes, confirm that the StatementExpression node is a traversal operation node, traverse the corresponding abstract syntax tree upward, obtain all parent nodes of the traversal operation node, and generate a parent node list; Traversing the parent node list, determining whether the parent node contains a conditional judgment statement, and checking whether the conditional judgment statement contains a null judgment operation on the data object; If the conditional judgment statement does not contain a null operation on the data object, it is confirmed that the corresponding StatementExpression node has a data object traversal exception and an exception report is generated.

2. The code traversal anomaly detection method according to claim 1, characterized in that: Traverse the corresponding abstract syntax tree upwards, obtain all parent nodes of the traversal operation node, and generate a parent node list, including: Marking the location information of the traversal operation node, recording the file name, line number and column number of the traversal operation node, for locating the abnormal code position; Recording the association relationship between the traversal operation node and the direct parent node, and establishing a hierarchical relationship of the traversal operation node in the context grammar structure; Using the hierarchical relationship, recursively search upward in the corresponding abstract syntax tree for all parent nodes of the traversal operation node, and mark the syntax type of each parent node, where the syntax type is used to identify the conditional judgment statement; Each parent node is stored in the parent node list according to the grammatical structure to generate a hierarchical parent node path.

3. The code traversal anomaly detection method according to claim 1, characterized in that: Traversing the parent node list, determining whether the parent node contains a conditional judgment statement, and checking whether the conditional judgment statement contains a null judgment operation on the data object, including: Traversing the parent node list, starting from the first node in the parent node list, and processing each parent node in turn; Determine the syntax type of each parent node to identify whether it is a conditional statement, wherein the conditional statement includes an if statement, an else if statement, and a switch statement; Analyze the identified conditional statements to check whether the conditional expressions contain a null check for the !=null of the data object in the traversal operation; If there is any conditional judgment statement that does not contain a null judgment operation, the corresponding traversal operation node is marked as an abnormal node.

4. The code traversal anomaly detection method according to claim 1, characterized in that: Generate exception reports including: Generate an exception report and list the StatementExpression nodes marked as abnormal, the exception report includes the file path, line number and column number of the abnormal node; Generate a repair suggestion based on the exception report, the repair suggestion includes adding a code example of a null judgment operation before the exception node! = null; Send the exception report and repair suggestions to the developer to inform the developer of the problem that needs to be handled; In the development environment, abnormal nodes are highlighted to help developers locate problematic codes. When the automatic repair instruction is received, a null check code is inserted before the abnormal node according to the repair suggestion, and the inserted code is marked.

5. The code traversal anomaly detection method as described in claim 1, characterized in that: Get the project source code folder and traverse the project source code folder, filter out the java files, and store them in the java file list, including: Extract the project source code folder from the project root directory, recursively traverse the subfolders in the project source code folder, and process each subfolder and the files contained in the subfolder layer by layer; During the traversal process, hidden files, non-code files, build folders, and test folders are filtered out based on file extensions, hidden attributes, and code file types in the project; Filter source code files with the extension .java, and store each filtered Java file path in the Java file list; Use file path identifiers to separate processed file paths from unprocessed file paths, and record the processing status of each file during the traversal process, including whether the file has been processed, the file processing time, and the processing result.

6. The code traversal anomaly detection method according to claim 1, characterized in that: Parse each java file in the java file list to generate a corresponding abstract syntax tree, including: Performing lexical analysis on the Java file, reading source code in the Java file line by line, and dividing the source code into lexical units, wherein the lexical units include keywords, identifiers, operators, and separators; Based on the lexical unit, a syntax analyzer is used to parse the source code in the Java file in sequence, and corresponding syntax nodes are generated according to the syntax structure of the Java language; An abstract syntax tree corresponding to the Java file is constructed based on the syntax nodes, wherein the abstract syntax tree is composed of a plurality of syntax nodes, and each syntax node represents a syntax structure element in the Java file.

7. The code traversal anomaly detection method according to claim 6, characterized in that: Perform lexical analysis on the Java file and read the source code in the Java file line by line, including: The Java files are grouped based on the size and historical processing time of the Java files in the Java file list, and each group of Java files is assigned to an independent thread for processing; Assign processing priority to each Java file based on its importance and modification time; The allocated independent threads read the source codes of the Java files in the group line by line according to the processing priority.

8. A code traversal anomaly detection device, characterized in that: The code traversal anomaly detection device comprises: A file management and screening module is used to obtain a project source code folder and traverse the project source code folder, screen out java files, and store them in a java file list; A code parsing module, used to parse each java file in the java file list and generate a corresponding abstract syntax tree; A traversal operation identification module is used to find a StatementExpression node representing an expression operation in each abstract syntax tree and determine whether the name attribute of the StatementExpression node ends with forEach or begins with for; A syntax tree traversal module is used to, if yes, confirm that the StatementExpression node is a traversal operation node, traverse the corresponding abstract syntax tree upwards, obtain all parent nodes of the traversal operation node, and generate a parent node list; A parent node analysis module is used to traverse the parent node list, determine whether the parent node contains a conditional judgment statement, and check whether the conditional judgment statement contains a null operation on the data object; The exception detection module is used to confirm that a data object traversal exception exists in the corresponding StatementExpression node if the conditional judgment statement does not contain a null operation on the data object.

9. A code traversal anomaly detection device, characterized in that: The code traversal anomaly detection device includes a memory, a processor, and a code traversal anomaly detection program stored in the memory and executable on the processor. When the code traversal anomaly detection program is executed by the processor, the steps of the code traversal anomaly detection method according to any one of claims 1 to 7 are implemented.

10. A computer storage medium, characterized in that: The storage medium stores a code traversal anomaly detection program, which, when executed by a processor, implements the steps of the code traversal anomaly detection method according to any one of claims 1 to 7.

Images