Hotfix method, device and medium for software tool development kit

Abstract

The present disclosure provides a hot fixing method, device, electronic equipment and medium of a software tool development package, wherein the method comprises: obtaining exception information of a target exception generated in a method to be fixed in a reflective call; identifying a target exception type of the target exception based on the exception information; wherein the target exception type is used to indicate whether the target exception is a known class exception set in advance; determining a fixing processing mode matched with the target exception type, and performing hot fixing processing on the target exception based on the fixing processing mode, so as to realize hot fixing processing on the method to be fixed.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a hot-fix method, apparatus, electronic device, and medium for a software tool development kit. Background Technology

[0002] Hotfix, also known as patching technology, refers to the emergency repair of an application using patches without the user's knowledge.

[0003] Currently, hotfix solutions at the application (APP) level are relatively mature. However, there are still few hotfix technologies at the software development kit (SDK) level. Existing SDK hotfix technologies typically involve directly modifying methods within a class, which generates reflection calls to those methods. However, existing hotfix technologies cannot accurately identify exceptions thrown during reflection calls, making it difficult to detect problems inherent in the SDK itself, potentially leading to more serious consequences. Summary of the Invention

[0004] This disclosure provides at least one hot-fix method, apparatus, electronic device, and medium for a software tool development kit.

[0005] In a first aspect, embodiments of this disclosure provide a hot-fix method for a software tool development kit, comprising: acquiring exception information of a target exception generated within a method to be fixed by reflection invocation; identifying the target exception type of the target exception based on the exception information; wherein the target exception type is used to indicate whether the target exception is a pre-set known class exception; determining a repair processing mode that matches the target exception type; and performing hot-fix processing on the target exception based on the repair processing mode, so as to achieve hot-fix processing on the method to be fixed.

[0006] In one optional implementation, identifying the target anomaly type based on the anomaly information includes: if the target anomaly is determined to be a reflected anomaly based on the anomaly information, obtaining the field content of the target anomaly field in the anomaly information; wherein the reflected anomaly is used to indicate that the target anomaly is an anomaly that is thrown after encapsulating an initial anomaly; identifying the true anomaly type of the encapsulated initial anomaly in the target anomaly based on the field content, and determining the true anomaly type as the target anomaly type.

[0007] In one optional implementation, identifying the true exception type of the initial exception encapsulated in the target exception based on the field content includes: obtaining a preset exception type declared in the method to be repaired; and determining the true exception type of the initial exception to be a first known class exception if the exception type indicated by the field content is the preset exception type.

[0008] In one optional implementation, identifying the true exception type of the initial exception encapsulated in the target exception based on the field content includes: determining the true exception type of the initial exception to be a second known class exception when it is determined that the exception type indicated by the field content is a runtime exception and the runtime exception is not a predefined runtime exception.

[0009] In one optional implementation, identifying the true exception type of the initial exception encapsulated in the target exception based on the field content includes: determining the true exception type of the initial exception as a first unknown class exception when it is determined that the exception type indicated by the field content is a runtime exception and the runtime exception is a predefined runtime exception.

[0010] In one optional implementation, identifying the target exception type of the target exception based on the exception information includes: if it is determined based on the exception information that the target exception is not a reflected exception, determining that the exception type of the target exception is a second unknown class exception; wherein the reflected exception is used to indicate that the target exception is an exception that is thrown after encapsulating the initial exception.

[0011] In one optional implementation, determining a repair processing mode that matches the target anomaly type and performing hot repair processing on the target anomaly based on the repair processing mode includes: if the target anomaly type is determined to be a known anomaly, throwing out the anomaly information of the target anomaly; or, if the target anomaly type is determined to be a non-known anomaly, generating new anomaly information based on the anomaly information of the target anomaly and throwing out the new anomaly information; wherein the type of anomaly indicated by the new anomaly information is a non-known anomaly.

[0012] Secondly, embodiments of this disclosure provide a hot-fixing device for a software tool development kit, comprising: an acquisition unit for acquiring exception information of a target exception generated within the object to be fixed by a reflection call; an identification unit for identifying the target exception type of the target exception based on the exception information; wherein the target exception type is used to indicate whether the target exception is a pre-set known exception type; a determination unit for determining a repair processing mode matching the target exception type; and a hot-fixing unit for performing hot-fixing processing on the target exception based on the repair processing mode, thereby achieving hot-fixing processing on the object to be fixed.

[0013] Thirdly, embodiments of this disclosure also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the first aspect above, or any possible implementation of the first aspect, are performed.

[0014] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the first aspect or any possible implementation of the first aspect.

[0015] In this embodiment, firstly, exception information of the target exception generated within the method to be repaired via reflection can be obtained. Then, the target exception type can be identified based on this exception information, thereby determining whether the target exception is a pre-defined known exception type. Different repair processing modes can be set for known and unknown exception types. Then, hot-fix processing is performed on the method to be repaired based on the repair processing mode matching the target exception type. This processing method ensures that reflection calls during hot-fix do not affect the original method's logical processing of exception information; simultaneously, it also distinguishes between unknown and known exception types, allowing for repair processing of the method to be repaired based on the identified exception type, thus achieving more comprehensive hot-fix of the SDK and ensuring the stable operation of the corresponding application.

[0016] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a hotfix method for a software tool development kit provided in an embodiment of this disclosure is shown.

[0019] Figure 2 A flowchart of an SDK repair method provided in an embodiment of this disclosure is shown;

[0020] Figure 3 The flowchart shown is a specific flowchart of a hotfix method for a software tool development kit provided in this disclosure, in which the target exception type is identified based on the exception information.

[0021] Figure 4 The flowchart shown is a hotfix method for a software tool development kit provided in an embodiment of this disclosure, which includes determining a repair processing mode that matches the target anomaly type and performing hotfix processing on the target anomaly based on the repair processing mode.

[0022] Figure 5 A flowchart is shown for a hotfix method for a second software tool development kit provided in this disclosure embodiment;

[0023] Figure 6 A flowchart is shown for a hotfix method of a third software tool development kit provided in this disclosure embodiment;

[0024] Figure 7 A schematic diagram of a hot-fix device for a software tool development kit provided in an embodiment of this disclosure is shown;

[0025] Figure 8 A schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0027] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0028] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0029] Research has revealed that while hotfix solutions at the application (APP) level are relatively mature, hotfix technologies at the software development kit (SDK) level are still relatively scarce. Existing SDK hotfix techniques typically involve directly modifying methods within a class, resulting in reflection calls to those methods. However, current hotfix technologies cannot accurately identify exceptions thrown during reflection calls, making it difficult to detect problems inherent in the SDK itself, potentially leading to more serious consequences.

[0030] In existing SDK hotfix technologies, exceptions thrown by the code being called via reflection are typically caught directly, then encapsulated into a new exception and thrown. However, this approach has the following drawbacks:

[0031] Disadvantage 1: Directly encapsulating exceptions thrown during reflection method calls makes it impossible to distinguish whether the exception is thrown due to a problem with the method itself (e.g., a known class exception, or an expected exception) or due to an error in the reflection call (e.g., an unknown class exception, or an unexpected exception). Exceptions thrown due to problems with the method itself can usually be handled according to the original method's processing logic. However, re-encapsulating the exception will cause exceptions that the original method might have thrown to be "swallowed," thus preventing the original method from handling the exception according to its original processing logic.

[0032] Disadvantage 2: If a new exception is thrown after an exception is caught, it will be difficult to distinguish the real cause of the new exception, which will reduce the user's trust in the hotfix technology; however, if a new exception is not thrown, the problems existing in the original method may be harder to discover, leading to more serious consequences.

[0033] Based on the above research, this disclosure provides a hotfix method for a software tool development kit (SDK). In this embodiment, firstly, exception information of the target exception generated within the method to be fixed via reflection is obtained; then, the target exception type can be identified based on this exception information, thereby determining whether the target exception is a pre-defined known exception type. Different repair processing modes can be set for known and unknown exception types, and then hotfix processing is performed on the method to be fixed based on the repair processing mode matching the target exception type. This processing method ensures that reflection calls during hotfix do not affect the original method's logical processing of exception information; simultaneously, it also distinguishes between unknown and known exception types, allowing for repair processing of the method to be fixed based on the identified exception type, thus achieving more comprehensive hotfix of the SDK and ensuring the stable operation of the corresponding application.

[0034] To facilitate understanding of this embodiment, a hot-fix method for a software tool development kit disclosed in this disclosure will first be described in detail. The hot-fix method for a software tool development kit provided in this disclosure is generally executed by an electronic device with a certain computing power.

[0035] See Figure 1 The diagram shows a flowchart of a hotfix method for a software tool development kit provided in this disclosure. The method includes steps S101 to S105, wherein:

[0036] S101: Obtain the exception information of the target exception generated inside the method to be repaired by reflection.

[0037] Here, reflection can be understood as: for any class, all its properties and methods can be called; and for any object contained in the class, any method and property of that object can be called.

[0038] In this embodiment, a patch package for a Software Development Kit (SDK) can be obtained and then run. The patch package can be a program for hot-fixing the SDK, achieved by modifying corresponding methods in the SDK's class files. During the modification of these methods, reflection calls to the methods are involved.

[0039] In practice, after SDK development is complete, a patch package can be generated and then deployed to the server. Before running the application, the client can query the server to see if the patch package exists. If the patch package is found, it downloads it from the server and runs it. The steps executed during the execution of the patch package constitute the execution steps of the hotfix method for the software tool development kit provided in this disclosure.

[0040] Here, based on the repair patch package described above, we can see that during the running of the repair patch package, the repair patch package will reflectively call the method to be repaired in the class file of the SDK to achieve the modification of the method to be repaired.

[0041] At this point, during the reflection call to the method to be repaired, the exception information of the target exception thrown inside the method to be repaired can be captured.

[0042] S103: Identify the target anomaly type of the target anomaly based on the anomaly information; wherein, the target anomaly type is used to indicate whether the target anomaly is a pre-set known anomaly type.

[0043] Here, the anomaly types of the target anomaly can be divided into known anomalies and unknown anomalies; among them, known anomalies can be understood as anomalies that meet expectations (or anomalies that can be predicted in advance), and unknown anomalies can be understood as anomalies that do not meet expectations (or anomalies that cannot be predicted in advance).

[0044] Known exceptions can include multiple sub-exception types, namely the first known exception and the second known exception described in the following embodiments.

[0045] Here, the first known exception class can be understood as: non-runtime exceptions declared in advance in the method to be repaired; the second known exception class can be understood as: custom runtime exceptions that are not declared in advance in the method to be repaired.

[0046] The method to be fixed contains the keyword "throws". By setting the corresponding key content for this keyword, the exception declared in the method to be fixed can be used as the exception.

[0047] The non-known class exception can include multiple sub-exception types, namely the first non-known class exception and the second non-known class exception described in the following embodiments.

[0048] Here, the first type of non-known exception can be understood as a system-defined runtime exception thrown due to a problem in the code executed by the method called via reflection. The second type of non-known exception can be understood as an exception caused during the reflection call due to reasons such as incorrect parameters.

[0049] S105: Determine a repair processing mode that matches the target anomaly type, and perform hot repair processing on the target anomaly based on the repair processing mode to achieve hot repair processing on the method to be repaired.

[0050] In this embodiment of the disclosure, after determining the target anomaly type, a repair processing mode matching the target anomaly type can be determined. This repair processing mode can be used to indicate how the target anomaly should be handled. The repair processing modes corresponding to known anomalies and unknown anomalies are different.

[0051] This approach ensures that reflection calls during hotfix do not affect the original method's logical processing of exception information. Furthermore, it allows for the differentiation between known and unknown exception types, enabling the method to be fixed to be repaired based on the identified exception type. This leads to more comprehensive hotfixing of the SDK, ensuring the stable operation of the corresponding application.

[0052] The following will combine Figure 2 This section provides a brief overview of the SDK repair process. For example... Figure 2 The diagram shown is a flowchart of an SDK repair method, which specifically includes the following steps:

[0053] Process 1: SDK Development Process: Compile the SDK to be fixed.

[0054] In practice, methods in the SDK that may require fixing can be instrumented to reserve a fixing interface for those methods. This can be done by writing a corresponding fixing interface program within the SDK. Afterwards, the instrumented methods can be recorded for easier management.

[0055] Process 2: Patch generation process: Compile and generate the patch package.

[0056] Add annotations to the methods that need to be fixed to mark the locations that need to be modified and to identify the pre-declared exceptions in the methods that need to be fixed; traverse the methods that need to be fixed, collect the patch's effectiveness information, and finally package and generate the patch.

[0057] Process 3: Patch deployment and client activation process:

[0058] Configure the features corresponding to the patch; then, upload the patch to the server for unified management and client download requests. At runtime, extract SDK features from the client, and then download the corresponding patches for each SDK from the server based on these features; merge all patches; and run the patch package according to the method provided in this embodiment to perform hot-fix processing on the methods to be repaired in the SDK.

[0059] In one alternative implementation, such as Figure 3 As shown, step S103 above identifies the target anomaly type based on the anomaly information, specifically including the following steps:

[0060] Step S1031: If the target exception is determined to be a reflected exception based on the exception information, the field content of the target exception field in the exception information is obtained; wherein, the reflected exception is used to indicate that the target exception is an exception that is thrown after encapsulating the initial exception.

[0061] Step S1032: Identify the true exception type of the initial exception encapsulated in the target exception based on the field content, and determine the true exception type as the target exception type.

[0062] In this embodiment of the disclosure, when an exception is thrown inside the method to be repaired that is invoked by reflection (i.e., the initial exception described in the above steps), since the exception cannot be represented in a uniform and clear way, the exception can be wrapped into a reflection exception InvocationTargetException and the wrapped InvocationTargetException reflection exception is thrown.

[0063] In the process of re-encapsulating the initial exception, the initial exception and its exception type can be encapsulated to obtain a new exception that contains the initial exception and its exception type, namely the reflection exception InvocationTargetException.

[0064] Therefore, after obtaining the exception information of the target exception, it is possible to determine whether the target exception is a reflection exception, InvocationTargetException, based on this information. If it is determined to be an InvocationTargetException, then the content of the Target Exception field can be extracted from the InvocationTargetException.

[0065] Here, the TargetException field can be used to indicate the true exception type of the unencapsulated exception (i.e., the initial exception) thrown inside the method to be fixed that is invoked by reflection.

[0066] Based on this, the target exception field "Target Exception" can be located in the reflection exception "InvocationTargetException", and its content can be extracted. The actual exception type of the initial exception can then be identified based on the extracted content. Finally, this actual exception type is determined to be the aforementioned target exception type.

[0067] In the above implementation, the method of identifying the true exception type of the initial exception thrown inside the method to be repaired by reflection by identifying the field content of the target exception field can more accurately and quickly identify the true exception type thrown by the method to be repaired. This allows for repair processing according to different repair processing modes for different types of exceptions, and thus the method to be repaired in the SDK can be repaired without affecting the original code logic, which is convenient for subsequent problem analysis and processing.

[0068] In an optional implementation, step S1032 above, which identifies the true exception type of the initial exception encapsulated in the target exception based on the field content, specifically includes the following steps:

[0069] S11: Obtain the preset exception type declared in the method to be repaired;

[0070] S12: If the exception type indicated by the field content is determined to be the preset exception type, the actual exception type of the initial exception is determined to be the first known class exception.

[0071] In this embodiment of the disclosure, during the generation of the repair patch package, the pre-declared exception type (i.e., the preset exception type) in each method to be repaired can be set in the repair patch package at the position corresponding to the method to be repaired. For example, the preset exception type can be set in the repair patch package as a corresponding string array. The pre-declared exception type in each method to be repaired is typically a non-runtime exception, RuntimeException.

[0072] In identifying the actual exception types mentioned above, an array of strings indicating pre-declared exception types in the method to be repaired can be obtained from the patch package. If the exception type indicated by the content of the target exception field is one of the strings obtained above, then the indicated exception type can be determined to be one of the pre-declared non-runtime exceptions (RuntimeException, i.e., pre-declared exception types) in the method to be repaired. At this point, the actual exception type of the initial exception can be determined to be an expected exception (i.e., the first known class exception) that might be thrown by the method called by reflection (i.e., the method to be repaired) by throwing the keyword `throws`.

[0073] If the actual exception type of the initial exception is determined to be a first known class exception, the exception information of the target exception can be thrown. For example, the exception information of the target exception can be thrown to an exception storage pool, where the method in the SDK used to handle the target exception can retrieve the exception information from the exception storage pool and process the target exception.

[0074] In an optional implementation, step S1032 above, which identifies the true exception type of the initial exception encapsulated in the target exception based on the field content, specifically includes the following steps:

[0075] S21: If it is determined that the exception type indicated by the field content is a runtime exception, and the runtime exception is not a predefined runtime exception, the true exception type of the initial exception is determined to be a second known class exception.

[0076] In this embodiment of the disclosure, if it is determined that the exception type indicated by the field content of the target exception field is not declared in the throw keyword, and it is determined that the exception type indicated by the field content of the target exception field is RuntimeException, wherein the RuntimeException is a custom RuntimeException, then it can be determined that the RuntimeException is not a predefined runtime exception, and the true exception type of the initial exception can be determined to be the exception thrown by the method called by reflection, which is the second known class exception.

[0077] In practice, it can be determined whether the RuntimeException indicated by the target exception field is an exception that begins with java.lang, such as java.lang.RuntimeException. If it is determined not to be one, then the runtime exception can be identified as either a custom RuntimeException or a non-system-defined RuntimeException.

[0078] If the actual exception type of the initial exception is determined to be a second known exception type, the exception information of the target exception can be thrown. For example, the exception information of the target exception can be thrown to an exception storage pool, where the method in the SDK used to handle the target exception can retrieve the exception information from the exception storage pool and process the target exception.

[0079] In an optional implementation, step S1032 above, which identifies the true exception type of the initial exception encapsulated in the target exception based on the field content, specifically includes the following steps:

[0080] S31: If it is determined that the exception type indicated by the field content is a runtime exception, and the runtime exception is a predefined runtime exception, the true exception type of the initial exception is determined to be a first unknown class exception.

[0081] In this embodiment of the disclosure, if it is determined that the exception type indicated by the field content of the target exception field is a runtime exception, and is a system-defined RuntimeException (i.e., a predefined runtime exception), then it can be determined that the exception is an unexpected exception (i.e., a first unknown class exception) caused by a logical exception (or code exception) of the method called by reflection.

[0082] In practice, it can be determined whether the RuntimeException indicated by the target exception field is an exception that begins with java.lang, such as java.lang.RuntimeException. If it is, then the runtime exception can be identified as a custom, system-defined RuntimeException.

[0083] Once the true exception type of the initial exception is determined to be the first unknown class exception, a new exception information can be redefined and thrown that includes the exception information. This facilitates the subsequent filtering out cases where unexpected exceptions are thrown, and at the same time provides basic information for determining the true cause of the exception.

[0084] In an optional implementation, step S103 above, which identifies the target anomaly type based on the anomaly information, specifically includes the following steps:

[0085] S41: If it is determined based on the anomaly information that the target anomaly is not a reflected anomaly, the anomaly type of the target anomaly is determined to be a second unknown anomaly; wherein, the reflected anomaly is used to indicate that the target anomaly is an anomaly that is thrown after encapsulating the initial anomaly.

[0086] In this embodiment of the disclosure, when an exception is thrown inside the method to be repaired that is invoked by reflection (i.e., the initial exception described in the above steps), since the exception cannot be represented in a uniform and clear way, the exception can be wrapped into a reflection exception InvocationTargetException and the wrapped InvocationTargetException reflection exception is thrown.

[0087] In the process of re-encapsulating the initial exception, the initial exception and its exception type can be encapsulated to obtain a new exception that contains the initial exception and its exception type, namely the reflection exception InvocationTargetException.

[0088] In this embodiment of the disclosure, after obtaining the exception information of the target exception, it can be determined whether the target exception is a reflected exception, InvocationTargetException, based on the exception information. If it is determined based on the exception information that the target exception is not an exception of type InvocationTargetException, then the target exception can be identified as a second unknown class exception.

[0089] Here, exceptions that are not of the InvocationTargetException type can be exceptions caused by errors in the parameters, method name, or other information of the reflection call.

[0090] If the true exception type of the initial exception is determined to be the second unknown class exception, a new exception information can be redefined and thrown that includes the exception information. This facilitates the subsequent filtering out cases where unexpected exceptions are thrown, and at the same time provides basic information for determining the true cause of the exception.

[0091] In the above implementation, reflection calls during the hotfix process can be made without affecting the original method's logical processing of exception information. At the same time, it can also distinguish between non-known exceptions and known exceptions, so that the method to be fixed can be fixed according to the identified exception type, thereby achieving a more comprehensive hotfix of the SDK and ensuring the stable operation of the corresponding application.

[0092] In one alternative implementation, such as Figure 4 As shown, step S105 above determines a repair processing mode that matches the target anomaly type, and performs hot repair processing on the target anomaly based on the repair processing mode, specifically including the following steps:

[0093] Step S1051: If the target exception type is determined to be a known type exception, the exception information of the target exception is thrown.

[0094] In this embodiment of the disclosure, if the actual exception type of the initial exception is determined to be either a first known class exception or a second known class exception, the exception information of the target exception can be thrown. For example, the exception information of the target exception can be thrown to an exception storage pool, wherein the method in the SDK for handling the target exception can retrieve the exception information from the exception storage pool and process the target exception.

[0095] Step S1052: If the target anomaly type is determined to be a non-known anomaly, new anomaly information is generated based on the anomaly information of the target anomaly, and the new anomaly information is thrown; wherein the type of the anomaly indicated by the new anomaly information is a non-known anomaly.

[0096] In this embodiment of the disclosure, if the true exception type of the initial exception is determined to be either a first unknown exception or a second unknown exception, a new exception information containing the exception information can be redefined and thrown. This facilitates the subsequent filtering out of cases where unexpected exceptions are thrown, and at the same time provides basic information for determining the cause of the true exception.

[0097] In practice, a new exception message can be generated, containing the same information as the target exception. Furthermore, an exception type identifier can be added to this new exception message to indicate that the exception it points to is a non-known exception type. In addition, the exception type identifier can also indicate the exception characteristics of this non-known exception type. For example, for a first non-known exception type, the exception type identifier can include sub-identifiers indicating the following information: system-defined RuntimeException; for a second non-known exception type, the exception type identifier can include sub-identifiers indicating the following information: incorrect parameters, incorrect method name, etc.

[0098] In the above implementation, by classifying the exceptions that may be thrown by the method being called via reflection into multiple types—known exceptions and unknown exceptions—different repair processes can be implemented for different types of exceptions. For example, expected exceptions (known exceptions) can be left unhandled, thus not affecting the logic of the code itself; unexpected exceptions (unknown exceptions) can be uniformly handled, which facilitates the rapid filtering and discovery of subsequent problems, as well as finding the true cause of the error based on the original exception that has been wrapped.

[0099] In embodiments of this disclosure, in such Figure 1 Based on the aforementioned embodiments, such as Figure 5 As shown, the method also includes the following steps:

[0100] S1001: Search for the preset exception type declared in the method to be repaired in the class file corresponding to the method to be repaired;

[0101] S1002: Obfuscate the type name of the preset exception type to obtain the name obfuscation result;

[0102] S1003: Based on the name obfuscation result and the method information of the method to be repaired, generate a repair patch package for the SDK.

[0103] In this embodiment of the disclosure, a repair patch package needs to be generated before repairing the Software Development Kit (SDK). The generated repair patch package contains pre-declared preset exception types in the method to be repaired (i.e., the method to be repaired mentioned above). Based on this, when the repair patch package is run, it can determine the actual exception type of the target exception based on the pre-declared preset exception types in the method to be repaired, and thus perform reasonable repair processing based on the actual exception type.

[0104] As described above, during the patch generation process, annotations can be added to the methods that need fixing in the source code to mark the locations requiring modification. Then, based on these annotations, the methods to be fixed in the source code can be identified, and the pre-declared exceptions (i.e., preset exception types) in the corresponding class file can be identified. Next, the type names of the preset exception types can be obfuscated to obtain a name obfuscation result; this name obfuscation result should be a name that the client can recognize. Finally, the name obfuscation result and the method information of the method to be fixed (e.g., method parameter information, method name, etc.) can be added to the patch package.

[0105] In an optional implementation, step S1001 above searches for a preset exception type declared in the method to be repaired in the class file corresponding to the method to be repaired, specifically including the following steps:

[0106] (1) Locate the file content corresponding to the method to be repaired in the class file;

[0107] (2) Search for the throw keyword in the file content and determine the key content corresponding to the throw keyword as the preset exception type.

[0108] In this embodiment, the file content corresponding to the method to be repaired in the class file can be identified. Based on this file content, the exception structure declared with the keyword `throws` that may be thrown can be found. Within this exception structure, the names of all possible exceptions declared to be thrown (i.e., preset exception types) can be determined. These names are then translated into names that the client can recognize according to obfuscation rules. Finally, the translated names are grouped into a string array, which, along with the method name, method parameters, and other information, is added to the repair patch package.

[0109] The following is combined Figure 6 This section introduces hotfix methods for software tool development kits. For example... Figure 6 The diagram shown is a flowchart of another hotfix method for a software tool development kit, such as... Figure 6 As shown, the method specifically includes the following steps:

[0110] S601: Search the file content corresponding to the method to be repaired in the class file, and determine the preset exception type declared in the method to be repaired in advance;

[0111] In this embodiment, the file content corresponding to the method to be repaired in the class file can be identified. Based on this file content, the exception structure declared with the keyword `throws` that may be thrown can be found. Within this exception structure, the names of all possible exceptions declared to be thrown (i.e., preset exception types) can be determined. These names are then translated into names that the client can recognize according to obfuscation rules. Finally, the translated names are grouped into a string array, which, along with the method name, method parameters, and other information, is added to the repair patch package.

[0112] S602: Obfuscate the type name of the preset exception type to obtain the name obfuscation result;

[0113] S603: Based on the name obfuscation result and the method information of the method to be repaired, generate a repair patch package for the SDK.

[0114] Next, the type names of the preset exception types can be obfuscated to obtain a name obfuscation result; this name obfuscation result can be a name that the client can recognize. Finally, the name obfuscation result and the method information of the method to be repaired (e.g., method parameter information, method name, etc.) can be added to the repair patch package.

[0115] S604: Run the repair patch package and obtain the exception information of the target exception generated inside the method to be repaired by reflection call;

[0116] S605: If the target anomaly is determined to be a reflection anomaly based on the anomaly information, obtain the field content of the target anomaly field in the anomaly information;

[0117] S606: If the exception type indicated by the field content is determined to be a preset exception type declared in the method to be repaired, the target exception type is determined to be a first known class exception; then, S610 can be executed to throw the exception information of the target exception.

[0118] In this embodiment of the disclosure, during the generation of the repair patch package, the pre-declared exception type (i.e., the preset exception type) in each method to be repaired can be set in the repair patch package at the position corresponding to the method to be repaired. For example, the preset exception type can be set in the repair patch package as a corresponding string array. The pre-declared exception type in each method to be repaired is typically a non-runtime exception, RuntimeException.

[0119] In identifying the actual exception types mentioned above, an array of strings indicating pre-declared exception types in the method to be repaired can be obtained from the patch package. If the exception type indicated by the content of the target exception field is one of the strings obtained above, then the indicated exception type can be determined to be one of the pre-declared non-runtime exceptions (RuntimeException, i.e., pre-declared exception types) in the method to be repaired. At this point, the actual exception type of the initial exception can be determined to be an expected exception (i.e., the first known class exception) that might be thrown by the method called by reflection (i.e., the method to be repaired) by throwing the keyword `throws`.

[0120] S607: If the exception type indicated by the field content is determined to be a runtime exception, and the runtime exception is not a predefined runtime exception, the target exception type is determined to be a second known class exception; then, S610 can be executed to throw the exception information of the target exception.

[0121] In this embodiment of the disclosure, if it is determined that the exception type indicated by the field content of the target exception field is not declared in the throw keyword, and it is determined that the exception type indicated by the field content of the target exception field is RuntimeException, wherein the RuntimeException is a custom RuntimeException, then it can be determined that the RuntimeException is not a predefined runtime exception, and the true exception type of the initial exception can be determined to be the exception thrown by the method called by reflection, which is the second known class exception.

[0122] In practice, it can be determined whether the RuntimeException indicated by the target exception field is an exception that begins with java.lang: java.lang.RuntimeException. If it is not, then the runtime exception can be determined to be either a custom RuntimeException or a non-system-defined RuntimeException.

[0123] S608: If the exception type indicated by the field content is determined to be a runtime exception, and the runtime exception is a predefined runtime exception, the target exception type is determined to be a first unknown class exception; then, S611 can be executed to generate new exception information based on the exception information of the target exception, and the new exception information is thrown.

[0124] In this embodiment of the disclosure, if it is determined that the exception type indicated by the field content of the target exception field is a runtime exception (runtimeException), and is a system-defined RuntimeException (i.e., a predefined runtime exception), then it can be determined that the exception is an unexpected exception (i.e., a first unknown class exception) caused by a logical exception (or code exception) of the method called by reflection.

[0125] In practice, it can be determined whether the RuntimeException indicated by the target exception field is an exception that begins with java.lang: java.lang.RuntimeException. If it is, then the runtime exception can be identified as a custom, system-defined RuntimeException.

[0126] S609: If it is determined based on the anomaly information that the target anomaly is not a reflected anomaly, the anomaly type of the target anomaly is determined to be a second unknown anomaly; wherein, the reflected anomaly is used to indicate that the target anomaly is an anomaly that is thrown after encapsulating the initial anomaly; then, S611 can be executed to generate new anomaly information based on the anomaly information of the target anomaly, and the new anomaly information can be thrown.

[0127] In this embodiment of the disclosure, when the method to be repaired, which is invoked by reflection, throws an exception (i.e., the initial exception described in the above steps), since the exception cannot be represented in a uniform and clear way, the exception can be wrapped into a reflection exception InvocationTargetException and the wrapped InvocationTargetException reflection exception is thrown.

[0128] In the process of re-encapsulating the initial exception, the initial exception and its exception type can be encapsulated to obtain a new exception that contains the initial exception and its exception type, namely the reflection exception InvocationTargetException.

[0129] In this embodiment of the disclosure, after obtaining the exception information of the target exception, it can be determined whether the target exception is a reflected exception, InvocationTargetException, based on the exception information. If it is determined based on the exception information that the target exception is not an exception of type InvocationTargetException, then the target exception can be identified as a second unknown class exception.

[0130] S610: Throw out the abnormal information of the target abnormality.

[0131] In this embodiment of the disclosure, if the actual exception type of the initial exception is determined to be either a first known class exception or a second known class exception, the exception information of the target exception can be thrown. For example, the exception information of the target exception can be thrown to an exception storage pool, wherein the method in the SDK for handling the target exception can retrieve the exception information from the exception storage pool and process the target exception.

[0132] S611: Generate new exception information based on the exception information of the target exception, and throw the new exception information; wherein the type of exception indicated by the new exception information is a non-known type exception.

[0133] In this embodiment of the disclosure, if the true anomaly type of the initial anomaly is determined to be either a first unknown anomaly or a second unknown anomaly, a new anomaly information containing that anomaly information can be redefined and thrown. This facilitates the subsequent filtering out of cases where unexpected anomalies are thrown, and at the same time provides basic information for determining the cause of the true anomaly.

[0134] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0135] Based on the same inventive concept, this disclosure also provides a software tool development kit (SDK) hot-fix device corresponding to the software tool development kit hot-fix method. Since the principle of the device in this disclosure for solving the problem is similar to the software tool development kit hot-fix method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0136] Reference Figure 7 The diagram shown is a schematic of a hot-fix device for a software development kit provided in this embodiment of the present disclosure. The device includes: an acquisition unit 10, an identification unit 20, a determination unit 30, and a hot-fix unit 40; wherein,

[0137] The acquisition unit 10 is used to acquire the exception information of the target exception generated inside the method to be repaired by reflection call;

[0138] The identification unit 20 is used to identify the target anomaly type of the target anomaly based on the anomaly information; wherein the target anomaly type is used to indicate whether the target anomaly is a pre-set known anomaly type;

[0139] The determining unit 30 is used to determine a repair processing mode that matches the target anomaly type;

[0140] The hot repair unit 40 is used to perform hot repair processing on the target anomaly based on the repair processing mode, so as to realize hot repair processing on the method to be repaired.

[0141] This approach ensures that reflection calls during hotfix do not affect the original method's logical processing of exception information. Furthermore, it allows for the differentiation between known and unknown exception types, enabling the method to be fixed to be repaired based on the identified exception type. This leads to more comprehensive hotfixing of the SDK, ensuring the stable operation of the corresponding application.

[0142] In one possible implementation, the identification unit is further configured to: when the target anomaly is determined to be a reflected anomaly based on the anomaly information, obtain the field content of the target anomaly field in the anomaly information; wherein the reflected anomaly is used to indicate that the target anomaly is an anomaly thrown after encapsulating an initial anomaly; identify the true anomaly type of the encapsulated initial anomaly in the target anomaly based on the field content, and determine the true anomaly type as the target anomaly type.

[0143] In one possible implementation, the identification unit is further configured to: obtain a preset exception type declared in the method to be repaired; and, if the exception type indicated by the field content is determined to be the preset exception type, determine the actual exception type of the initial exception to be a first known class exception.

[0144] In one possible implementation, the identification unit is further configured to: determine the true exception type of the initial exception as a second known class exception when it is determined that the exception type indicated by the field content is a runtime exception and the runtime exception is not a predefined runtime exception.

[0145] In one possible implementation, the identification unit is further configured to: determine the true exception type of the initial exception as a first unknown class exception when it is determined that the exception type indicated by the field content is a runtime exception and the runtime exception is a predefined runtime exception.

[0146] In one possible implementation, the identification unit is further configured to: determine the exception type of the target exception as a second unknown class exception if it is determined based on the exception information that the target exception is not a reflected exception; wherein the reflected exception is used to indicate that the target exception is an exception that is thrown after encapsulating the initial exception.

[0147] In one possible implementation, the hot-repair unit is further configured to: if the target anomaly type is determined to be a known anomaly, throw out the anomaly information of the target anomaly; or, if the target anomaly type is determined to be a non-known anomaly, generate new anomaly information based on the anomaly information of the target anomaly, and throw out the new anomaly information; wherein the type of anomaly indicated by the new anomaly information is a non-known anomaly.

[0148] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0149] Corresponding to Figure 1 The hot-fix method of the software tool development kit in this disclosure also provides an electronic device 800, such as... Figure 8 The diagram shown is a structural schematic of an electronic device 800 provided in an embodiment of this disclosure, including:

[0150] The system includes a processor 81, a memory 82, and a bus 83. The memory 82 stores execution instructions and includes main memory 821 and external memory 822. The main memory 821, also called internal memory, temporarily stores the computational data in the processor 81, as well as data exchanged with external memory such as a hard disk. The processor 81 exchanges data with the external memory 822 through the main memory 821. When the electronic device 800 is running, the processor 81 communicates with the memory 82 through the bus 83, causing the processor 81 to execute the following instructions:

[0151] Obtain the exception information of the target exception generated inside the method to be repaired by reflection call;

[0152] The target anomaly type is identified based on the anomaly information; wherein, the target anomaly type is used to indicate whether the target anomaly is a pre-defined known anomaly type.

[0153] A repair processing mode matching the target anomaly type is determined, and a hot repair process is performed on the target anomaly based on the repair processing mode to achieve hot repair processing on the method to be repaired.

[0154] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the hot-fix method of the software tool development kit described in the above method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0155] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of the hot-fix method of the software tool development kit described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0156] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0157] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0158] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0159] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0160] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0161] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A hotfix method for a software tool development kit, characterized in that, include: Obtain the exception information of the target exception generated inside the method to be repaired by reflection call; The target anomaly type is identified based on the anomaly information; wherein, the target anomaly type is used to indicate whether the target anomaly is a pre-defined known anomaly type. A repair processing mode matching the target anomaly type is determined, and a hot repair process is performed on the target anomaly based on the repair processing mode to achieve hot repair processing on the method to be repaired. The method of identifying the target anomaly type based on the anomaly information includes: determining whether the target anomaly is a reflection anomaly based on the anomaly information, wherein the reflection anomaly is used to indicate that the target anomaly is an anomaly that encapsulates an initial anomaly and then throws it out. The step of determining a repair processing mode that matches the target anomaly type, and performing hot repair processing on the target anomaly based on the repair processing mode, includes: If the target exception type is determined to be a known type exception, the exception information of the target exception is thrown; or If the target anomaly type is determined to be a non-known anomaly, new anomaly information is generated based on the anomaly information of the target anomaly, and the new anomaly information is thrown; wherein the anomaly type indicated by the new anomaly information is a non-known anomaly.

2. The method according to claim 1, characterized in that, The method of identifying the target anomaly type based on the anomaly information further includes: If the target anomaly is determined to be the reflection anomaly based on the anomaly information, the field content of the target anomaly field in the anomaly information is obtained; Based on the content of the field, identify the true exception type of the initial exception encapsulated in the target exception, and determine the true exception type as the target exception type.

3. The method according to claim 2, characterized in that, The step of identifying the true exception type of the initial exception encapsulated within the target exception based on the field content includes: Obtain the pre-declared preset exception type in the method to be repaired; If the exception type indicated by the field content is determined to be the preset exception type, the actual exception type of the initial exception is determined to be the first known class exception.

4. The method according to claim 2, characterized in that, The step of identifying the true exception type of the initial exception encapsulated within the target exception based on the field content includes: If the exception type indicated by the field content is determined to be a runtime exception, and the runtime exception is not a predefined runtime exception, then the true exception type of the initial exception is determined to be a second known class exception.

5. The method according to claim 2, characterized in that, The step of identifying the true exception type of the initial exception encapsulated within the target exception based on the field content includes: If the exception type indicated by the field content is determined to be a runtime exception, and the runtime exception is a predefined runtime exception, then the true exception type of the initial exception is determined to be a first unknown class exception.

6. The method according to claim 1, characterized in that, The method of identifying the target anomaly type based on the anomaly information further includes: If, based on the anomaly information, it is determined that the target anomaly is not the reflection anomaly, then the anomaly type of the target anomaly is determined to be a second unknown anomaly.

7. A hot-fix device for a software tool development kit, characterized in that, include: The acquisition unit is used to acquire exception information of the target exception generated inside the method to be repaired by reflection call; The identification unit is used to identify the target anomaly type of the target anomaly based on the anomaly information; wherein the target anomaly type is used to indicate whether the target anomaly is a pre-set known anomaly type; A determining unit is used to determine a repair processing mode that matches the target anomaly type; A hot repair unit is used to perform hot repair processing on the target anomaly based on the repair processing mode, so as to realize hot repair processing on the method to be repaired; The method of identifying the target anomaly type based on the anomaly information includes: determining whether the target anomaly is a reflection anomaly based on the anomaly information, wherein the reflection anomaly is used to indicate that the target anomaly is an anomaly that encapsulates an initial anomaly and then throws it out. The step of determining a repair processing mode that matches the target anomaly type, and performing hot repair processing on the target anomaly based on the repair processing mode, includes: If the target exception type is determined to be a known type exception, the exception information of the target exception is thrown; or If the target anomaly type is determined to be a non-known anomaly, new anomaly information is generated based on the anomaly information of the target anomaly, and the new anomaly information is thrown; wherein the anomaly type indicated by the new anomaly information is a non-known anomaly.

8. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the hot-fix method of the software tool development kit as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the hot-fix method of the software tool development kit as described in any one of claims 1 to 6.

Images