Method of processing code, method of processing exceptions and respective apparatuses

Abstract

The embodiment of the present specification provides a method for processing code, a method for processing exceptions and respective devices, wherein the method for processing code comprises: reading a bytecode file generated after a program source code is compiled; locating a code region in a target method contained in the bytecode file which needs to capture an exception; and performing an exception capture block adding process on the code region based on a bytecode operation mode to obtain a processed bytecode file, wherein the exception capture block adding process comprises: adding a start label of a monitored block at the beginning of the code region, adding an end label of the monitored block at the end of the code region, and adding a corresponding exception processing block for the monitored block, wherein the exception processing block is used for processing an exception captured by the monitored block.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technology, and more particularly to methods for processing code and methods for handling exceptions. One or more embodiments of this specification also relate to apparatuses for processing code, apparatuses for handling exceptions, computing devices, and computer-readable storage media. Background Art

[0002] With the advancement of computer technology, software products offer increasingly rich functionality. Software products, such as SDKs (Software Development Kits), can integrate with vendor applications to enhance their capabilities. Because software products integrate with applications from different vendors, the stability of each vendor's library varies. The software products themselves can also experience various anomalies due to issues like test case coverage and the vendor's application's scenario adaptability. These anomalies can cause application crashes, resulting in a poor user experience for the vendor's application.

[0003] Therefore, how to enhance stability has become a very core consideration for software products. Summary of the Invention

[0004] In view of this, embodiments of this specification provide methods for processing code and methods for handling exceptions. One or more embodiments of this specification also involve apparatuses for processing code, apparatuses for handling exceptions, computing devices, and computer-readable storage media to address technical deficiencies in the prior art.

[0005] According to a first aspect of an embodiment of the present specification, a method for processing code is provided, comprising: reading a bytecode file generated after compiling program source code; locating a code region in a target method contained in the bytecode file that needs to capture exceptions; and processing the code region with an exception capture block based on a bytecode operation mode to obtain a processed bytecode file, wherein the processing of adding the exception capture block comprises: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to process the exception captured by the monitored block.

[0006] Optionally, the locating of the code area in the target method contained in the bytecode file that needs to capture exceptions includes: traversing the target method in the bytecode file based on the MethodVisitor interface provided by the ASM framework; the processing of adding an exception capture block to the code area based on the bytecode operation mode includes: based on the MethodVisitor interface, each time a target method is traversed, adding a start tag of the monitored block to the start position of the original code of the target method, adding an end tag of the monitored block to the end position of the original code of the target method, and adding a corresponding exception handling block to the monitored block.

[0007] Optionally, adding the start label of the monitored block at the start position of the original code of the target method includes: using onMethodEnter of the MethodVisitor interface, or using the first entry of visitLabel of the MethodVisitor interface to add the start label of the monitored block at the start position of the original code of the target method.

[0008] Optionally, adding the end tag of the monitored block at the end position of the original code of the target method and adding a corresponding exception handling block for the monitored block include: using onMethodExit of the MethodVisitor interface to add the end tag of the monitored block at the end position of the original code of the target method, and obtaining the return value of the target method through the interpreter, and adding the corresponding exception handling block after the end tag of the monitored block by calling the code block addition program corresponding to the type of the return value.

[0009] According to the second aspect of the embodiments of this specification, there is provided a device for processing code, comprising: a reading module configured to read a bytecode file generated after compiling the program source code. A positioning module configured to locate the code area in the target method contained in the bytecode file that needs to capture exceptions. A code adding module configured to process the code area by adding an exception capture block based on the bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception capture block includes: adding a start tag of the monitored block at the beginning of the code area, adding an end tag of the monitored block at the end of the code area, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to process the exception captured by the monitored block.

[0010] According to a third aspect of the embodiments of this specification, a method for handling exceptions is provided, comprising: when a software product is connected to an application and running, capturing an exception based on a monitored block in the software product, wherein the software product is generated based on a bytecode file, the bytecode file being a bytecode file obtained by compiling program source code and adding an exception capturing block based on a bytecode operation mode, the exception capturing block including a monitored block and an exception handling block, the start tag of the monitored block being located at the beginning of a code region in a target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block being located at the end of the code region; and handling the exception based on the exception handling block in the software product.

[0011] Optionally, the method further includes: capturing cross-thread exceptions by capturing global exceptions to obtain exception information; determining whether the exception information comes from a child thread; if so, determining a method that triggers the exception information; determining whether the method is a method within the software product; if so, processing the exception corresponding to the exception information.

[0012] Optionally, the processing the exception based on the exception handling block in the software product includes: based on the exception handling block in the software product, preventing the exception captured by the monitored block from being transmitted to the system on which the program runs.

[0013] Optionally, the processing the exception based on the exception handling block in the software product further includes: reporting the exception captured by the monitored block to an exception handling platform based on the exception handling block in the software product.

[0014] According to a fourth aspect of the embodiments of this specification, a device for handling exceptions is provided, comprising: a capture module configured to capture exceptions based on a monitored block in a software product when a software product is connected to an application and running, wherein the software product is generated based on a bytecode file, the bytecode file being a bytecode file obtained by compiling program source code and adding an exception capture block based on a bytecode operation mode, the exception capture block comprising a monitored block and an exception handling block, the start tag of the monitored block being located at the beginning of a code region in a target method where exceptions need to be captured, the end tag of the monitored block and the exception handling block being located at the end of the code region. A processing module configured to handle the exception based on the exception handling block in the software product.

[0015] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions: reading a bytecode file generated by compiling program source code, locating a code region in a target method contained in the bytecode file that needs to capture exceptions, and adding an exception capture block to the code region based on a bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception capture block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block to the monitored block. The exception handling block is used to process exceptions captured by the monitored block; or, when the software product is connected to an application and runs, the exception is captured based on the monitored block in the software product, wherein the software product is generated based on a bytecode file, which is a bytecode file obtained by compiling program source code and adding an exception capture block based on a bytecode operation mode, the exception capture block includes a monitored block and an exception handling block, the start tag of the monitored block is located at the beginning of a code area in the target method where the exception needs to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code area; the exception is processed based on the exception handling block in the software product.

[0016] According to the sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, the steps of the method for processing codes described in any embodiment of this specification are implemented, or the steps of the method for handling exceptions described in any embodiment of this specification are implemented.

[0017] One embodiment of this specification provides a method for processing code. This method reads a bytecode file generated after compiling program source code, locates a code region within a target method contained in the bytecode file that requires exception capture, and automatically adds an exception capture block to the code region based on a bytecode operation method to obtain a processed bytecode file. Therefore, generating a software product based on the processed bytecode file can effectively improve code processing efficiency and avoid the programmer manually adding exception capture blocks during the development phase, which reduces efficiency and makes the code unreadable. Furthermore, because the addition of the exception capture block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to handle exceptions captured by the monitored block. Therefore, the method for processing code provided in this embodiment of the specification can add an exception capture module to a code region that requires monitoring in a software product, thereby enabling timely protection and handling of exceptions within the software product during runtime, preventing the system from killing abnormal threads and causing application crashes, and effectively enhancing the stability of the software product.

[0018] Another embodiment of the present specification provides a method for handling exceptions. Since the software product in this method is generated based on a bytecode file, and the bytecode file is a bytecode file obtained by compiling the program source code and adding an exception catching block based on the bytecode operation mode, the exception catching block includes a monitored block and an exception handling block, the start label of the monitored block is located at the beginning of the code area in the target method where the exception needs to be caught, and the end label of the monitored block and the exception handling block are located at the end of the code area, that is, the software product is a software product generated by the bytecode file obtained after the exception catching block is automatically and dynamically inserted. Therefore, when the software product is connected to the application and runs, it can catch exceptions based on the monitored block in the software product and perform protection processing on the exception based on the exception handling block in the software product, so as to avoid the system killing the abnormal thread and causing the application to crash, thereby effectively enhancing the stability of the software product. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is a flowchart of a method for processing codes provided by one embodiment of this specification;

[0020] Figure 2 This is a schematic diagram of the Gradle Transform mechanism provided by an embodiment of this specification;

[0021] Figure 3 This is a code diagram provided by an embodiment of this specification;

[0022] Figure 4This is a code diagram of onMethodEnter provided in one embodiment of this specification;

[0023] Figure 5 This is a schematic diagram of an exception table provided in one embodiment of this specification;

[0024] Figure 6 This is a schematic diagram of an exception table provided in another embodiment of this specification;

[0025] Figure 7 This is a schematic diagram of the visitLable code provided by an embodiment of this specification;

[0026] Figure 8 This is a schematic diagram of the onMethodExit code provided in one embodiment of this specification;

[0027] Figure 9 This is a schematic diagram of the onMethodExit code provided in another embodiment of this specification;

[0028] Figure 10 This is a schematic diagram of the structure of a code processing device provided by an embodiment of this specification;

[0029] Figure 11 This is a flowchart of a method for handling an exception provided by an embodiment of this specification;

[0030] Figure 12 is a flowchart of a method for handling an exception provided by another embodiment of this specification;

[0031] Figure 13 This is a schematic diagram of the structure of a device for handling an exception provided by an embodiment of this specification;

[0032] Figure 14 is a structural diagram of a device for handling an exception provided by another embodiment of this specification;

[0033] Figure 15 This is a structural block diagram of a computing device provided by one embodiment of this specification. DETAILED DESCRIPTION

[0034] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0035] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0036] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0037] First, the terms involved in one or more embodiments of this specification are explained.

[0038] A crash is a sudden exit of an application running on the system due to an exception. The process causing the exception is killed and restarted.

[0039] Mobile terminals, such as the two mobile terminal ecological fields of Android system and iOS system.

[0040] To make the methods provided in the embodiments of this specification easier to understand, we first analyze and explain some implementation methods for exception capture and exception handling: To enhance the stability of a software product, exception capture is essential. One approach is to customize the capture of unhandled exceptions in a thread, while another approach is to add an exception capture block to the target method (e.g., an exception capture block, based on a Java try catch block). The first approach can capture almost all Java virtual machine exceptions, but if the exception occurs in the main thread, it cannot be protected and blocked by a system alarm, otherwise it will cause a system alarm. Therefore, the first approach may cause some logic in the vendor's application to fail to execute. The second approach uses an exception capture block to relatively accurately control exceptions within the software product without causing alarms in the main thread. However, during the development phase, it is clearly not feasible for R&D personnel to manually wrap each target method with an exception capture block, which would render the code unreadable and lead to low development efficiency. Based on this, the code processing method provided in the embodiments of this specification can utilize a bytecode-based operation method, such as the ASM framework (a universal Java bytecode operation and analysis framework), to automatically add an exception capture block to the code area in the target method that needs to capture exceptions during compilation. The method for handling exceptions provided in the embodiments of this specification can handle exceptions based on a software product to which an exception catching block is added.

[0041] Below, the code processing method, exception processing method, code processing device, exception processing device, computing device and computer-readable storage medium provided in this specification are described in detail one by one in the following embodiments.

[0042] Figure 1 A flowchart of a method for processing code according to an embodiment of the present specification is shown, including steps 102 to 106.

[0043] Step 102: Read the bytecode file generated after compiling the program source code.

[0044] For example, the program source code may be a program source code based on a JVM language.

[0045] Step 104: Locate the code area in the target method included in the bytecode file that needs to catch the exception.

[0046] For example, part or all of the code in one or more target methods can be used as the code area that needs to catch exceptions, which can be specifically set according to the needs of the implementation scenario. For example, in one or more embodiments, the entire code of each method included in the bytecode file can be used as the code area that needs to catch exceptions.

[0047] Step 106: Add an exception catching block to the code area based on the bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception catching block includes: adding a start tag of the monitored block at the beginning of the code area, adding an end tag of the monitored block at the end of the code area, and adding a corresponding exception handling block to the monitored block, wherein the exception handling block is used to process the exception caught by the monitored block.

[0048] For example, a software product may be generated based on the bytecode file after the exception catching block processing is added.

[0049] Because this method reads the bytecode file generated after compiling the program source code, locates the code area in the target method contained in the bytecode file that needs to catch exceptions, and automatically adds exception catching blocks to the code area in batches based on the bytecode operation mode to obtain the processed bytecode file, generating a software product based on the processed bytecode file can effectively improve code processing efficiency and avoid the programmer manually adding exception catching blocks during the development phase, which reduces efficiency and makes the code unreadable. Moreover, because the process of adding the exception catching block includes: adding the start tag of the monitored block at the beginning of the code area, adding the end tag of the monitored block at the end of the code area, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to handle the exceptions caught by the monitored block, the code processing method provided in the embodiments of this specification can add an exception catching module to the code area that needs to be monitored in the software product, so that the software product can promptly protect and handle exceptions within the software product during operation, avoiding the system killing the abnormal thread and causing the application to crash, effectively enhancing the stability of the software product.

[0050] Among them, the specific implementation method of the exception handling logic of the exception handling block is not limited, as long as the exception can be protected and processed to avoid the application crash. For example, in one or more embodiments of this specification, the exception handling logic may include: preventing the exception captured by the monitored block from being passed to the system on which the program is running. In this embodiment, by preventing the exception from being returned to the system, the exception is blocked within the scope of the software product, effectively avoiding the system from being informed of the exception and killing the process, causing the application to crash. After the exception is blocked from returning to the system, in order to further accurately analyze and process the cause of the exception, the exception handling logic may also include: reporting the captured exception to the exception handling platform, so that the exception handling platform can further analyze and process the exception in a variety of ways. For example, the exception handling platform can be the service provider of the software product.

[0051] It should be noted that the code processing methods provided in the embodiments of this specification do not limit the specific implementation of the bytecode manipulation methods for dynamically modifying bytecodes. For example, the ASM framework is a general Java bytecode manipulation and analysis framework. Operations based on the various interfaces and methods provided by the ASM framework can dynamically modify bytecodes according to the code processing methods provided in the embodiments of this specification.

[0052] In order to be able to comprehensively handle exceptions occurring in software products, in one or more embodiments of this specification, the entire code area of ​​each method is used as the code area that needs to capture exceptions. Therefore, the positioning of the code area that needs to capture exceptions in the method contained in the bytecode file can include: traversing the methods in the bytecode file based on the MethodVisitor interface provided by ASM. The processing of adding exception capture blocks to the code area based on the bytecode operation mode includes: based on the MethodVisitor interface, each time a target method is traversed, the start tag of the monitored block is added to the starting position of the original code of the target method, the end tag of the monitored block is added to the end position of the original code of the target method, and a corresponding exception handling block is added to the monitored block.

[0053] MethodVisitor is the core interface provided by ASM. It can be used to traverse the various components of a method (such as signature, annotations, parameters, exceptions, etc.). Exception catching blocks can be added during the traversal process.

[0054] More specifically, for example, the code processing method provided in the embodiments of this specification can be implemented in combination with Gradle's Transform mechanism. Figure 2The diagram below shows Gradle's Transform mechanism, which dynamically processes bytecode files after compilation. For example, an app source code file passes through the Java compiler to generate one or more class files. These class files, such as a.class, b.class, ...z.class, enter Transform node 1 for bytecode modification, adding try / catch blocks. Transform node 1 is powered by the ASM framework. The MethodVisitor interface provided by the ASM framework can be used in two ways: through a ClassReader and a ClassWriter. First, the ClassReader traverses the method to locate the instructions corresponding to the exception catch block. Then, the ClassWriter adds the corresponding instructions, resulting in the processed bytecode files, such as a.class, b.class, ...z.class. The processed bytecode files can then enter other Transform nodes for subsequent processes, such as obfuscation. After Dex-based, packaging, and compression, the final result is the software product APK file.

[0055] The following is a detailed explanation of the specific use of the core MethodVisitor interface of the ASM framework.

[0056] For example, Figure 3 As shown in the code diagram, if trycatch is added at the beginning and end of the target method methodA, the code structure after adding is roughly as follows Figure 3 As shown in the example, a try block (monitored block) start tag "try{" is added to the beginning of the target method, methodA. A try block end tag "}" and a catch block (exception handling block) "catch(Exception e){...}" are added to the end of the target method. ExceptionHandler.processException(e) corresponds to the exception handling logic. The catch block calls ExceptionHandler.processException(e) to uniformly process caught exceptions.

[0057] It should be noted that the MethodVisitor interface provides a variety of methods that can be used to modify bytecode. The following describes how to use the MethodVisitor interface to add the start tag of the monitored block:

[0058] For example, visitCode and visitEnd. visitCode and visitEnd are instruction visit methods that can be used to visit the entry and exit of the target method. visitCode and visitEnd can be used to add exception catch blocks.

[0059] For another example, AdviceAdapter simplifies the use of MethodVisitor. As a professional method modifier, it provides the onMethodEnter method, which will be called when entering the target method. It represents the entrance of the target method and is more convenient to use. Therefore, onMethodEnter can be used to add the start tag of the monitored block at the beginning of the original code of the target method. Specifically, Figure 4 The code diagram of using onMethodEnter shown in the figure adds the start label of the monitored block try block at the entry of the target method. The start of the try block is the entry of the target method.

[0060] For another example, by rewriting the visitLable method, the first entry of the visitLabel of the MethodVisitor interface can be used to add the start label of the monitored block at the beginning of the original code of the target method. This embodiment is mainly used to solve the problem of Exception Table misordering.

[0061] The reason why the Exception Table is out of order is that in the class file, there is an exception table at the end of each method, which is treated as an attribute. When ASM handles exceptions, there will be a visitTryCatchBlock() callback, and each try catch block in the corresponding code, including the try catch block added later, will also be called back through visitTryCatchBlock. Using javap-c to view the disassembled code of a class file without an additional try catch block, you can see that there is an exception table at the end of the method. Figure 5The exception table is shown. If you add a try catch block directly in onMethodEnter without any special processing, the code you see when decompiling the class file through the IDE is normal, but there will be problems during execution, because all exceptions inside the method are not caught and processed by the try catch block of the original code of the target method, but are all processed by the try catch block newly added to onMethodEnter. This is because, by modifying the bytecode file through onMethodEnter, a monitored block containing the entire method body is added at the beginning of the code. The code you see when disassembling by adding a try catch block directly in onMethodEnter is as follows Figure 6 As shown, the first exception in the exception table is the one caught by the newly added try catch block. This includes all the existing code from lines 0 to 15, from the beginning to the end of the try block. If the catch block is a Throwable exception, all Exception and Error inherited from Throwable will be handled by it. This is the problem of the Exception Table being out of order.

[0062] To solve the Exception Table out-of-order problem, based on the mechanism that visitTryCatchBlock is accessed before visitLabel, a custom exception catch block trycatch block can be added to the target method when visitLabel is first called. This ensures that the custom exception catch block is added only after all the original try catch blocks in the target method code have been processed, ensuring that the custom exception catch block try catch block is added to the end of the exception table. So in this embodiment, you can do the following: Figure 7 The visitLable code diagram shown in the figure rewrites the visitLable method and utilizes the first entry of the visitLabel of the MethodVisitor interface to add the start label of the monitored block at the beginning of the original code of the target method. Figure 7 The Label in the code diagram shown is used to mark the code location, such as the starting point of try catch, the target location of jump, etc.

[0063] Next, the implementation method of adding the end tag of the monitored block and adding the corresponding exception handling block to the monitored block using the MethodVisitor interface is described:

[0064] For example, another life cycle function of AdviceAdapter, onMethodExit, represents the end of the target method. Figure 8 The onMethodExit code diagram shown in the figure shows that, using onMethodExit, you can add the end tag of the monitored block, namely the try end tag "}", after processing the original method code. This ensures that the original code of the entire target method is surrounded by the newly added "try{" and "}". Then, add the exception handling catch block code.

[0065] It should be noted that Figure 8 The code diagram shown only considers the case where the return value is of type void. In fact, the return value of the target method may be one of a variety of data types, such as primitive type, non-primitive type class, integer type, long type, string type, etc. Therefore, considering this situation, Figure 9 The onMethodExit code diagram shown in the figure shows that in onMethodExit, the return type can be judged and then categorized. The return type of the target method can be obtained through the interpreter's "descriptor" when the MethodVisitor is constructed. For example, if the interpreter obtains an integer, the corresponding code block program for the integer is called; if it is a void type, the corresponding code block program for the void type is called; if it is a long type, the corresponding code block program for the long type is called. The processing logic of the code block program corresponding to each return type is the same, and the corresponding exception handling block is added.

[0066] In addition, if Figure 9 As can be seen from the code diagram shown, the code processing method provided in the embodiment of this specification also judges the event of "ATHROW". This is because: there is a situation where an exception is thrown inside the target method itself. Specifically, in ASM, an exception thrown by the target method will be regarded as the end of the target method, and the event opcode triggered is "ATHROW". Since onMethodExit represents the end of the method, when an exception is thrown, onMethodExit will be triggered. For this type of exception, according to the needs of the implementation scenario, the exception can be eaten by directly returning. Of course, you can also choose to continue throwing. If you need to eat the exception, you can filter the opcode in the onMethodExit code. If it is ATHROW, just return without doing any processing.

[0067] Corresponding to the above-mentioned method embodiment for processing code, this specification also provides an embodiment of an apparatus for processing code. Figure 10 FIG1 shows a schematic diagram of a device for processing codes according to an embodiment of the present specification. Figure 10 As shown, the device includes: a reading module 1002 , a positioning module 1004 and a code adding module 1006 .

[0068] The reading module 1002 may be configured to read a bytecode file generated after program source code is compiled.

[0069] The positioning module 1004 may be configured to locate a code region in the target method included in the bytecode file where an exception needs to be caught.

[0070] The code adding module 1006 can be configured to add an exception catching block to the code area based on a bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception catching block includes: adding a start tag of the monitored block at the beginning of the code area, adding an end tag of the monitored block at the end of the code area, and adding a corresponding exception handling block to the monitored block, wherein the exception handling block is used to handle the exception caught by the monitored block.

[0071] Because the device reads the bytecode file generated after compiling the program source code, locates the code area in the target method contained in the bytecode file that needs to capture exceptions, and automatically adds an exception capture block to the code area based on the bytecode operation mode to obtain a processed bytecode file, generating a software product based on the processed bytecode file can effectively improve code processing efficiency and avoid the programmer manually adding exception capture blocks during the development phase, which reduces efficiency and makes the code unreadable. Moreover, because the process of adding the exception capture block includes: adding the start tag of the monitored block at the beginning of the code area, adding the end tag of the monitored block at the end of the code area, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to handle the exceptions captured by the monitored block, the code processing device provided in the embodiments of this specification can add an exception capture module to the code area that needs to be monitored in the software product, so that when the software product is running, the software product can promptly protect the exception from being processed internally, avoiding the system killing the abnormal thread and causing the application to crash, effectively enhancing the stability of the software product.

[0072] The positioning module 1004 can be configured to traverse the target method in the bytecode file based on the MethodVisitor interface provided by ASM. The code adding module 1006 can be configured to add the start tag of the monitored block to the beginning of the original code of the target method and the end tag of the monitored block to the end of the original code of the target method based on the MethodVisitor interface, and add a corresponding exception handling block to the monitored block.

[0073] For example, the code adding module 1006 may be configured to add the start label of the monitored block at the beginning of the original code of the target method using onMethodEnter of the MethodVisitor interface or the first entry of visitLabel of the MethodVisitor interface.

[0074] For another example, the code adding module 1006 can be configured to use onMethodExit of the MethodVisitor interface to add the end tag of the monitored block at the end of the original code of the target method, and obtain the return value of the target method through the interpreter, and add the corresponding exception handling block after the end tag of the monitored block by calling the code block addition program corresponding to the type of the return value.

[0075] The above is a schematic diagram of a code processing device according to this embodiment. It should be noted that the technical solution of the code processing device and the technical solution of the code processing method described above are based on the same concept. For details not described in detail in the technical solution of the code processing device, please refer to the description of the technical solution of the code processing method described above.

[0076] The following combined Figure 11 , describes the method for handling exceptions provided in this manual. Figure 11 A flowchart of a method for handling an exception according to an embodiment of the present specification is shown, including steps 1102 to 1104 .

[0077] Step 1102: When the software product is connected to the application and running, exceptions are captured based on a monitored block in the software product, wherein the software product is generated based on a bytecode file, which is a bytecode file obtained by compiling program source code and adding an exception capture block based on a bytecode operation mode. The exception capture block includes a monitored block and an exception handling block, the start tag of the monitored block is located at the beginning of a code region in the target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code region.

[0078] Step 1104: Process the exception based on the exception handling block in the software product.

[0079] Since the software product in this method is generated based on a bytecode file, and the bytecode file is a bytecode file obtained by compiling the program source code and adding an exception catching block based on the bytecode operation mode, the exception catching block includes a monitored block and an exception handling block, the start label of the monitored block is located at the beginning of the code area in the target method where the exception needs to be caught, and the end label of the monitored block and the exception handling block are located at the end of the code area, that is, the software product is a software product generated by the bytecode file obtained after the exception catching block is automatically and dynamically inserted. Therefore, when the software product is connected to the application and runs, it can catch exceptions based on the monitored block in the software product and perform protection processing on the exceptions based on the exception handling block in the software product, thereby preventing the system from killing the abnormal thread and causing the application to crash, thereby effectively enhancing the stability of the software product.

[0080] According to the method for handling exceptions, method-level protection can be performed on software products. However, method-level protection cannot handle cross-thread exceptions. Therefore, the method provided in the embodiments of this specification can also capture thread exceptions for threads that cannot be handled by the try catch block, and then perform stack analysis to handle the exceptions. Specifically, Figure 12 A flowchart of a method for handling an exception provided according to this embodiment is shown, including steps 1202 to 1214.

[0081] Step 1202: When the software product is connected to the application program and is running, an exception is captured based on a monitored block in the software product.

[0082] Step 1204: Process the exception based on the exception handling block in the software product.

[0083] Step 1206: Capture cross-thread exceptions by capturing global exceptions to obtain exception information.

[0084] Step 1208: Determine whether the abnormal information comes from a child thread.

[0085] Step 1210: If yes, determine the method that caused the exception information.

[0086] Step 1212: Determine whether the method is a method within the software product.

[0087] Step 1214: If yes, process the exception corresponding to the exception information.

[0088] For example, the exception handling logic may prevent the exception captured by the monitored block from being transmitted to the system on which the program is running. Furthermore, the exception captured by the monitored block may be reported to the exception handling platform.

[0089] It can be seen that according to Figure 12 In the illustrated embodiment, the exception handling method provided in the embodiments of this specification may further include: capturing cross-thread exceptions by capturing global exceptions to obtain exception information; determining whether the exception information originates from a child thread; if so, determining the method that caused the exception information; determining whether the method is within the software product; if so, handling the exception corresponding to the exception information. This embodiment effectively supplements exceptions that cannot be handled by the exception capture block, further enhancing the stability of the software product.

[0090] Specifically, for example, exceptions can be captured by registering the UncaughtExceptionHandler of the thread. The captured information is stored in the stack. By intercepting the stack information with keywords such as "Back trace starts" and "Backtrace ends", the core stack information that caused the exception can be obtained. By splitting according to keywords such as "at", the methods at each level of the stack that caused the exception can be determined. According to the pre-set package name (for example, it can be a list of all package names of the software product), the method that caused the exception determined in the previous step is searched. Once the package name with the corresponding inclusion relationship is found, it can be determined that the exception occurred inside the software product and the protection relationship is satisfied. For exceptions that need to be protected, the transmission to the terminal system on which the application is running is prevented and reported to the exception handling platform.

[0091] In combination with the above-mentioned multiple embodiments, in the method for handling exceptions provided in the embodiments of this specification, the software product may be an SDK with a number authentication function, and the application connected to the SDK may run on a mobile terminal. According to the method for handling exceptions provided in the embodiments of this specification, the try catch mechanism of java may be used to block exceptions within the code of the software product and report them to the platform for processing. Moreover, when using asm to perform method-level protection on the SDK, custom processing of uncaught exceptions is further performed on the thread. If it is an exception of the main thread, no processing is performed. If it is an exception of the child thread, the analysis stack indicates that it occurs inside the SDK, and the exception is prevented from returning to the mobile terminal system on which the vendor program connected to the SDK runs. This prevents the mobile terminal system from receiving an exception and killing the thread, causing the application to crash, effectively enhancing the stability of the SDK and improving the user experience.

[0092] Corresponding to the above-mentioned method embodiment for handling an exception, this specification also provides an embodiment of an apparatus for handling an exception. Figure 13 FIG1 shows a schematic diagram of a structure of an apparatus for handling anomalies provided by an embodiment of this specification. Figure 13 As shown, the device includes: a capturing module 1302 and a processing module 1304 .

[0093] The capture module 1302 can be configured to capture exceptions based on a monitored block in the software product when the software product is connected to an application and running. The software product is generated based on a bytecode file. The bytecode file is a bytecode file obtained by compiling program source code and adding an exception capture block based on a bytecode operation method. The exception capture block includes a monitored block and an exception handling block. The start tag of the monitored block is located at the beginning of a code area in the target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code area.

[0094] The processing module 1304 may be configured to process the exception based on an exception handling block in the software product.

[0095] Since the software product in the device is generated based on a bytecode file, and the bytecode file is a bytecode file obtained by compiling the program source code and adding an exception catching block based on the bytecode operation mode, the exception catching block includes a monitored block and an exception handling block, the start label of the monitored block is located at the beginning of the code area in the target method where the exception needs to be caught, and the end label of the monitored block and the exception handling block are located at the end of the code area, that is, the software product is a software product generated by the bytecode file obtained after the exception catching block is automatically and dynamically inserted. Therefore, when the software product is connected to the application and runs, it can catch exceptions based on the monitored block in the software product and perform protection processing on the exceptions based on the exception handling block in the software product, so as to avoid the system killing the abnormal thread and causing the application to crash, thereby effectively enhancing the stability of the software product.

[0096] Figure 14 FIG. 1 shows a schematic diagram of a device for handling anomalies according to another embodiment of the present invention. Figure 14As shown, the device for handling exceptions may also include: a cross-thread exception capture module 1306, which can be configured to capture cross-thread exceptions by capturing global exceptions to obtain exception information. A thread judgment module 1308, which can be configured to determine whether the exception information comes from a child thread. A method determination module 1310, which can be configured to determine the method that triggers the exception information if the thread judgment module 1308 determines that it is yes. A scope judgment module 1312, which can be configured to determine whether the method is a method within the software product. A thread exception handling module 1314, which can be configured to handle the exception corresponding to the exception information if the scope judgment module 1312 determines that it is yes.

[0097] Among them, the thread exception handling module 1314 can be configured to prevent the exception captured by the monitored block from being transmitted to the system on which the program runs based on the exception handling block in the software product, or, further, report the exception captured by the monitored block to the exception handling platform.

[0098] The above is a schematic diagram of an apparatus for handling an exception according to this embodiment. It should be noted that the technical solution of the apparatus for handling an exception is the same as the technical solution of the method for handling an exception described above. For details not described in detail in the technical solution of the apparatus for handling an exception, please refer to the description of the technical solution of the method for handling an exception.

[0099] Figure 15 15 shows a block diagram of a computing device 1500 according to one embodiment of the present disclosure. Components of the computing device 1500 include, but are not limited to, a memory 1510 and a processor 1520. The processor 1520 is connected to the memory 1510 via a bus 1530, and a database 1550 is used to store data.

[0100] The computing device 1500 also includes an access device 1540 that enables the computing device 1500 to communicate via one or more networks 1560. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 1540 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0101] In one embodiment of the present specification, the above components of the computing device 1500 and Figure 15 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 15 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0102] Computing device 1500 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. Computing device 1500 can also be a mobile or stationary server.

[0103] The processor 1520 is configured to execute the following computer-executable instructions:

[0104] Reading a bytecode file generated after compiling the program source code, locating a code region in a target method contained in the bytecode file that needs to capture exceptions, and adding an exception capture block to the code region based on a bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception capture block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block to the monitored block, wherein the exception handling block is used to process the exception captured by the monitored block;

[0105] or,

[0106] When a software product is connected to an application and runs, exceptions are captured based on a monitored block in the software product. The software product is generated based on a bytecode file, which is a bytecode file obtained by compiling program source code and adding an exception capture block based on a bytecode operation mode. The exception capture block includes a monitored block and an exception handling block. The start tag of the monitored block is located at the beginning of a code region in a target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code region. The exception is handled based on the exception handling block in the software product.

[0107] The above is a schematic diagram of a computing device according to this embodiment. It should be noted that the technical solution of this computing device shares the same concept as the technical solutions of the aforementioned code processing method and exception handling method. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solutions of the aforementioned code processing method and exception handling method.

[0108] An embodiment of the present specification further provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, are used to:

[0109] Reading a bytecode file generated after compiling the program source code, locating a code region in a target method contained in the bytecode file that needs to capture exceptions, and adding an exception capture block to the code region based on a bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception capture block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block to the monitored block, wherein the exception handling block is used to process the exception captured by the monitored block;

[0110] or,

[0111] When a software product is connected to an application and runs, exceptions are captured based on a monitored block in the software product. The software product is generated based on a bytecode file, which is a bytecode file obtained by compiling program source code and adding an exception capture block based on a bytecode operation mode. The exception capture block includes a monitored block and an exception handling block. The start tag of the monitored block is located at the beginning of a code region in a target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code region. The exception is handled based on the exception handling block in the software product.

[0112] The above is a schematic diagram of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium is based on the same concept as the technical solutions of the aforementioned code processing method and exception handling method. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solutions of the aforementioned code processing method and exception handling method.

[0113] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0114] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0115] It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0116] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0117] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for processing code, comprising: Read the bytecode file generated after compiling the program source code; Locating a code region in a target method included in the bytecode file where an exception needs to be caught, wherein the code region where the exception needs to be caught includes a portion of a code region in the target method; Adding an exception catching block to the code region during compilation based on a bytecode operation mode to obtain a processed bytecode file, wherein the adding of the exception catching block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to handle exceptions caught by the monitored block, and the bytecode operation mode is an ASM framework; Based on the exception handling block, preventing the exception caught by the monitored block from being propagated to the system on which the program is running; Capture cross-thread exceptions by capturing global exceptions to obtain exception information; Determine whether the abnormal information comes from the child thread; If so, determine the method that caused the exception information; Determining whether the method is a method within a software product; If yes, process the exception corresponding to the exception information.

2. The method according to claim 1, wherein locating a code region in a target method included in the bytecode file that needs to catch an exception comprises: Traverse the target method in the bytecode file based on the MethodVisitor interface provided by the ASM framework; The process of adding an exception catching block to the code area based on the bytecode operation mode includes: Based on the MethodVisitor interface, each time a target method is traversed, the start tag of the monitored block is added to the beginning position of the original code of the target method, the end tag of the monitored block is added to the end position of the original code of the target method, and a corresponding exception handling block is added to the monitored block.

3. The method according to claim 2, wherein adding a start tag of the monitored block at the beginning of the original code of the target method comprises: By using onMethodEnter of the MethodVisitor interface or the first entry of visitLabel of the MethodVisitor interface, a start label of the monitored block is added to the beginning of the original code of the target method.

4. The method according to claim 2, wherein adding an end tag of the monitored block at the end of the original code of the target method and adding a corresponding exception handling block to the monitored block comprises: Using onMethodExit of the MethodVisitor interface, add the end tag of the monitored block at the end of the original code of the target method, and obtain the return value of the target method through the interpreter. By calling the code block addition program corresponding to the type of the return value, add the corresponding exception handling block for the monitored block.

5. A device for processing code, comprising: A reading module is configured to read a bytecode file generated after compiling the program source code; a positioning module configured to locate a code region in a target method included in the bytecode file where an exception needs to be caught, wherein the code region where the exception needs to be caught includes a portion of a code region in the target method; a code adding module configured to add an exception catching block to the code region during compilation based on a bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception catching block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block to the monitored block, wherein the exception handling block is used to handle exceptions caught by the monitored block, and the bytecode operation mode is an ASM framework; A cross-thread exception capture module is configured to, based on the exception handling block, prevent the exception captured by the monitored block from being transmitted to the system on which the program is running; capture cross-thread exceptions by capturing global exceptions to obtain exception information; Determine whether the abnormal information comes from the child thread; If so, determine the method that caused the exception information; Determining whether the method is a method within a software product; If yes, process the exception corresponding to the exception information.

6. A method for handling an exception, comprising: When a software product is connected to an application and is running, exceptions are captured based on a monitored block in the software product, wherein the software product is generated based on a bytecode file, which is a bytecode file obtained by compiling program source code and adding an exception capture block during compilation based on a bytecode operation mode, wherein the exception capture block includes a monitored block and an exception handling block, wherein the start tag of the monitored block is located at the beginning of a code region in a target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code region, wherein the bytecode operation mode is an ASM framework, wherein the code region where exceptions need to be captured includes a portion of a code region in the target method; Processing the exception based on an exception handling block in the software product; processing the exception based on the exception handling block in the software product includes: preventing the exception captured by the monitored block from being transmitted to the system on which the program is running based on the exception handling block in the software product; Capture cross-thread exceptions by capturing global exceptions to obtain exception information; Determine whether the abnormal information comes from the child thread; If so, determine the method that caused the exception information; Determining whether the method is a method within the software product; If yes, process the exception corresponding to the exception information.

7. The method according to claim 6, wherein the processing of the exception based on the exception handling block in the software product further comprises: Based on the exception handling block in the software product, the exception captured by the monitored block is reported to the exception handling platform.

8. A device for handling an exception, comprising: a capture module configured to capture exceptions based on a monitored block in a software product when the software product is connected to an application and running, wherein the software product is generated based on a bytecode file, the bytecode file being a bytecode file obtained by compiling program source code and adding an exception capture block during compilation based on a bytecode operation mode, the exception capture block including a monitored block and an exception handling block, the start tag of the monitored block being located at the beginning of a code region in a target method where exceptions need to be captured, the end tag of the monitored block and the exception handling block being located at the end of the code region, the bytecode operation mode being an ASM framework, and the code region where exceptions need to be captured including a portion of a code region in the target method; a processing module configured to process the exception based on an exception handling block in the software product; the processing module further configured to prevent the exception captured by the monitored block from being transmitted to the system on which the program is running based on the exception handling block in the software product; A cross-thread exception capture module is configured to capture cross-thread exceptions by capturing global exceptions to obtain exception information; Determine whether the abnormal information comes from the child thread; If so, determine the method that caused the exception information; Determining whether the method is a method within the software product; If yes, process the exception corresponding to the exception information.

9. A computing device comprising: memory and processor; The memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions: Reading a bytecode file generated after compiling the program source code, locating a code region in a target method contained in the bytecode file that needs to capture exceptions, and adding an exception capture block to the code region during compilation based on a bytecode operation mode to obtain a processed bytecode file, wherein the process of adding the exception capture block includes: adding a start tag of a monitored block at the beginning of the code region, adding an end tag of the monitored block at the end of the code region, and adding a corresponding exception handling block for the monitored block, wherein the exception handling block is used to process exceptions captured by the monitored block, the bytecode operation mode is an ASM framework, and the code region that needs to capture exceptions includes a portion of the code region in the target method; Based on the exception handling block, preventing the exception caught by the monitored block from being propagated to the system on which the program is running; Capture cross-thread exceptions by capturing global exceptions to obtain exception information; Determine whether the abnormal information comes from the child thread; If so, determine the method that caused the exception information; Determining whether the method is a method within a software product; If yes, handle the exception corresponding to the exception information; or, When a software product is connected to an application and is running, exceptions are captured based on a monitored block in the software product, wherein the software product is generated based on a bytecode file, which is a bytecode file obtained by compiling program source code and adding an exception capture block during compilation based on a bytecode operation mode, wherein the exception capture block includes a monitored block and an exception handling block, wherein the start tag of the monitored block is located at the beginning of a code region in a target method where exceptions need to be captured, and the end tag of the monitored block and the exception handling block are located at the end of the code region, wherein the bytecode operation mode is an ASM framework, wherein the code region where exceptions need to be captured includes a portion of a code region in the target method; Processing the exception based on an exception handling block in the software product; processing the exception based on the exception handling block in the software product includes: preventing the exception captured by the monitored block from being transmitted to the system on which the program is running based on the exception handling block in the software product; To capture cross-thread exceptions by capturing global exceptions and obtain exception information; Determine whether the abnormal information comes from the child thread; If so, determine the method that caused the exception information; Determining whether the method is a method within the software product; If yes, process the exception corresponding to the exception information.

10. A computer-readable storage medium storing computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the steps of the method for processing codes according to any one of claims 1 to 4 are implemented, or the steps of the method for processing exceptions according to any one of claims 6 to 7 are implemented.

11. A computer program product, characterized in that The method comprises computer instructions, which, when executed by a processor, implement the steps of the method for processing codes according to any one of claims 1 to 4, or implement the steps of the method for processing exceptions according to any one of claims 6 to 7.

Images