Exception handling method, computer device and computer program product

By identifying and distinguishing exception types in asynchronous tasks, using the built-in logic of the asynchronous task to handle the first exception, and entrust an asynchronous framework program to handle the second exception, solving the problem of the failure to handle the exception in the prior art that causes interrupts or crashes, and improving the stability and reliability of the application.

CN120371573APending Publication Date: 2025-07-25XFUSION DIGITAL TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510100719.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-21
Publication Date
2025-07-25

AI Technical Summary

Technical Problem

The prior art cannot effectively capture and handle exception types that may cause application interruptions or crashes, such as program interrupt exceptions caused by keyboard interrupt operations, affecting system stability and reliability.

Method used

By identifying exception types in an asynchronous task and using the built-in logical processing of the asynchronous task for the first exception type, delegating the asynchronous framework program processing for the second exception type, ensuring differentiated exception handling logic, including identifying exception types, obtaining error information, controlling the execution of flow transfer, performing specified operations, etc.

Benefits of technology

Improves the stability and reliability of the application, avoids system crashes and exposure of internal error messages, and ensures a friendly user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120371573A_ABST
    Figure CN120371573A_ABST
Patent Text Reader

Abstract

The invention is suitable for the technical field of computers, and provides an exception handling method, computer equipment and a computer program product.The exception handling method comprises the steps that in the asynchronous task running process, exceptions caused by exceptional events are recognized, and exception types are obtained; if the exception type is a first exception type, exception processing is executed based on exception processing logic in the asynchronous task, and a first processing result is obtained; if the exception type is a second exception type, performing exception processing based on the specified program to obtain a second processing result; wherein the first exception type represents an exception caused by an error condition, the second exception type represents an exception caused by stopping the asynchronous task, and the specified program is an asynchronous framework program on which the asynchronous task runs. According to the method, the stability and the reliability of the application program can be ensured through differentiated exception handling modes.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of computer technology, and particularly relates to an exception handling method, a computer device, and a computer program product. Background Art

[0002] With the popularization of microservice architectures and distributed systems, backend services have become increasingly complex. An exception handling mechanism can effectively manage errors between different services, improving the maintainability and scalability of the system. A reasonable exception handling mechanism can capture and handle unexpected situations, prevent system crashes, enhance the stability and reliability of the system, and avoid directly exposing internal error information to users, reducing security risks.

[0003] In related technologies, existing exception handling mechanisms can usually only capture exceptions caused by error conditions. For example, an exception caused by a zero divisor that may occur during a division operation, etc. These exceptions do not cause the application to interrupt, exit, or directly crash. However, exceptions that may cause the application to interrupt, exit, or directly crash (such as a program interruption exception caused by a keyboard interrupt operation, etc.) cannot be captured. When these exceptions occur, if they cannot be captured and properly handled in a timely manner, it will lead to errors inside the program, and then the system cannot normally respond to requests, seriously affecting the overall stability and reliability of the application. Summary of the Invention

[0004] In view of this, embodiments of this application provide an exception handling method, a computer device, and a computer program product, which can improve the stability and reliability of an application through a differentiated exception handling method.

[0005] The first aspect of the embodiments of this application provides an exception handling method, including:

[0006] During the running of an asynchronous task, identify an exception caused by an exception event to obtain an exception type;

[0007] If the exception type is a first exception type, perform exception handling based on the exception handling logic in the asynchronous task to obtain a first processing result;

[0008] If the exception type is a second exception type, perform exception handling based on a specified program to obtain a second processing result;

[0009] Wherein, the first exception type represents an exception caused by an error condition, the second exception type represents an exception that stops the asynchronous task, and the specified program is an asynchronous framework program on which the asynchronous task depends.

[0010] In an implementation of the first aspect, performing exception handling based on the exception handling logic in the asynchronous task to obtain a first processing result includes:

[0011] Obtaining the error information of the exception event;

[0012] Based on the error information, matching a target subtype from the multiple subtypes included in the first exception type;

[0013] Controlling the execution flow of the asynchronous task to transfer to the sub-exception handling logic adapted to the target subtype;

[0014] Executing the sub-exception handling logic to obtain a first processing result.

[0015] In an implementation of the first aspect, performing exception handling based on a specified program to obtain a second processing result includes:

[0016] Determining the specified operation that triggers the exception event;

[0017] Based on the specified program, performing a target operation on the asynchronous task to obtain a second processing result, where the second processing result indicates that the asynchronous task has terminated execution, and the target operation is adapted to the specified operation.

[0018] In an implementation of the first aspect, the exception event includes a keyboard interrupt event, the keyboard interrupt event is triggered by an input operation of a keyboard instruction, and the exception type of the keyboard interrupt event is identified as the second exception type,

[0019] The specified operation is the input operation of the keyboard instruction, and based on the specified program, performing a target operation on the asynchronous task includes:

[0020] Directly interrupting the execution of the asynchronous task based on the specified program.

[0021] In an implementation of the first aspect, the exception event includes a cancellation execution event, the cancellation execution event is triggered by a cancel task operation, and the exception type of the cancellation execution event is identified as the second exception type,

[0022] The specified operation is the cancel task operation, and based on the specified program, performing a target operation on the asynchronous task includes:

[0023] Based on the specified program, restoring the resources whose operation or occupation has changed based on the asynchronous task and terminating the execution of the asynchronous task.

[0024] In an implementation of the first aspect, the method further includes:

[0025] If the exception type is an unknown exception type, an error response message is generated based on a preset fixed error code and error message;

[0026] Among them, the unknown exception type represents an exception type other than the first exception type and the second exception type.

[0027] In an implementation manner of the first aspect, before identifying the exception caused by the exception event during the running of the asynchronous task and obtaining the exception type, the method further includes:

[0028] If an asynchronous request sent by the terminal device is received, the asynchronous task is run, and the asynchronous task is used to respond to the asynchronous request;

[0029] When the exception type is the first exception type, the method further includes:

[0030] The first processing result is encapsulated in a preset format to obtain an encapsulation result;

[0031] The encapsulation result is used as the response information of the asynchronous request and fed back to the terminal device for display.

[0032] In an implementation manner of the first aspect, before identifying the exception type of the captured exception event, the method further includes:

[0033] Register a global exception handler in the running environment of the asynchronous task;

[0034] Among them, the global exception handler encapsulates the exception handling strategy for each exception type, and the global exception handler is used to implement the exception handling method as described above.

[0035] A second aspect of the embodiments of the present application provides an exception handling device, including:

[0036] An identification module, configured to identify an exception caused by an exception event during the running of an asynchronous task and obtain an exception type;

[0037] A processing module, configured to, if the exception type is the first exception type, perform exception handling based on the exception handling logic in the asynchronous task to obtain a first processing result;

[0038] The processing module is further configured to, if the exception type is the second exception type, perform exception handling based on a specified program to obtain a second processing result;

[0039] Among them, the first exception type represents an exception caused by an error condition, the second exception type represents an exception caused by stopping the asynchronous task, and the specified program is an asynchronous framework program on which the asynchronous task depends.

[0040] In a third aspect of the embodiments of the present application, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the computer device implements the method described in the first aspect above.

[0041] In a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in the first aspect above is implemented.

[0042] In a fifth aspect of the embodiments of the present application, a computer program product is provided, including a computer program. When the computer program is run, the method described in the first aspect above is executed.

[0043] In the first aspect of the embodiments of the present application, during the running of an asynchronous task, by identifying the exception type of an exception caused by an exception event, the source of the exception can be located, and the first exception type caused by an error condition and the second exception type caused by stopping the asynchronous task operation can be distinguished. For the first exception type, the built-in exception handling logic is used to handle the exception to obtain a first processing result. For the second exception type, the asynchronous framework program is used to handle the exception to obtain a second processing result. In this way, the stability and reliability of the application program can be improved through differentiated exception handling methods.

[0044] It can be understood that the beneficial effects of the second to fifth aspects above can be referred to the relevant descriptions in the first aspect above, and will not be repeated here. Description of the Drawings

[0045] To more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0046] Figure 1 is a flowchart of the Sanic framework exception handling mechanism provided by the related art;

[0047] Figure 2 is a schematic flowchart of the exception handling method provided by the embodiments of the present application;

[0048] Figure 3 It is a schematic flowchart of an exception handling method for the first exception type provided by an embodiment of the present application;

[0049] Figure 4 It is a schematic flowchart of an exception handling method for the second exception type provided by an embodiment of the present application;

[0050] Figure 5 It is an example diagram of exception handling for the second exception type provided by an embodiment of the present application;

[0051] Figure 6 It is a schematic flowchart of an exception handling method for an unknown exception type provided by an embodiment of the present application;

[0052] Figure 7 It is a schematic flowchart of an exception handling method for an unknown exception type provided by an embodiment of the present application;

[0053] Figure 8 It is a schematic flowchart of an exception handling method for global exception handling provided by an embodiment of the present application;

[0054] Figure 9 It is a schematic diagram of the architecture of an exception handling system provided by an embodiment of the present application;

[0055] Figure 10 It is another schematic flowchart of an exception handling method provided by an embodiment of the present application;

[0056] Figure 11 It is a schematic diagram of an exception handling device provided by an embodiment of the present application;

[0057] Figure 12 It is a schematic diagram of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0058] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system architectures, technologies, etc. are presented to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0059] It should be understood that when used in the specification and appended claims of the present application, the term "comprising" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0060] It should also be understood that the term "and / or" as used in the specification and appended claims of this application refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0061] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when", "once", "in response to determining", or "in response to detecting" depending on the context. Similarly, the phrase "if determined" or "if [the described condition or event] is detected" can be interpreted as meaning "once determined", "in response to determining", "once [the described condition or event] is detected", or "in response to detecting [the described condition or event]" depending on the context.

[0062] In addition, in the description of the specification and appended claims of this application, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0063] Reference to "one embodiment" or "some embodiments" etc. described in the specification of this application means that a specific feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in another way.

[0064] In applications, the well-known Sanic framework is a lightweight, high-performance Python web framework, especially suitable for building asynchronous web applications and services. In terms of exception handling, in Python, the BaseException type is the base class of all built-in exceptions. The Exception type inherits from the BaseException type. Among them, all built-in non-system exit class exceptions are derived from the Exception type, and all user-defined exceptions should also be derived from the Exception type. For the Exception type, the Sanic framework provides a flexible exception handling mechanism to manage exceptions that may occur during the running of the program. Such as Figure 1The flowchart of the exception handling mechanism of the Sanic framework is shown as follows. The specific processing process is as shown in the figure. During the process of a computer device running an asynchronous task receiving a front-end request for business processing, it first determines whether an exception event is triggered. If no exception event is triggered, it directly responds to the front-end request. If an exception event is triggered, it identifies whether the exception type of the exception caused by the exception event is an exception of the Exception type. If so, it defines a known exception error code and returns the exception information. If it is an exception of a non-Exception type, the operating system of the computer device running the asynchronous task or the runtime environment provided by the computer device for the asynchronous task directly throws an error message containing technical terms and internal details, which may also cause the asynchronous task to block or the system to crash.

[0065] In addition, there are multiple non-Exception type exceptions in Python, such as the SystemExit type, the KeyboardInterrupt type, and the CancelledError type, etc. Among them, the SystemExit type is triggered by the sys.exit() function. It inherits from the BaseException type rather than the Exception type, and the SystemExit type will not be accidentally caught by the exception handling logic for the Exception type. The KeyboardInterrupt type is also an exception that inherits from the BaseException type, which indicates that the user has interrupted the program (usually by pressing Ctrl+C). In the Sanic framework, when a request or task is cancelled, an exception of the CancelledError type will be triggered. The CancelledError type is a subclass of BaseException and is used to represent the situation where a request or task is cancelled.

[0066] However, it should be noted that the exception handling mechanism of the Sanic framework currently mainly supports the handling of exceptions of the Exception type. This means that if the above non-Exception type exceptions (such as the SystemExit type, the KeyboardInterrupt type, the CancelledError type, etc.) are thrown in a program that depends on the Sanic framework to run, these exceptions will not be caught by the exception handling mechanism of the Sanic framework. This may cause internal program errors, unable to respond to user requests normally, thus affecting the continuity of the service and the user experience, and is also not conducive to the stability and reliability of the system.

[0067] Based on this, the embodiments of the present application provide an exception handling method, which can provide differentiated exception handling logics for different exception types to improve the stability and reliability of the application program. Next, the exception handling method will be described in detail.

[0068] In one embodiment, as Figure 2 shown, an exception handling method is provided. Taking the case where this method is applied to a computer device that deploys asynchronous tasks as an example, it includes the following steps S101 to S103:

[0069] Step S101, during the running of the asynchronous task, identify the exception caused by the exception event to obtain the exception type.

[0070] In an application, an exception event refers to a triggering factor that causes an exception in an asynchronous task. The triggering factor may be a logical error within the program or an improper operation by the user. During the execution of the asynchronous task, the computer device identifies the exceptions caused by various exception events to obtain the exception type, and adopts different exception handling mechanisms for exception events of different exception types.

[0071] Step S102, if the exception type is the first exception type, perform exception handling based on the exception handling logic in the asynchronous task to obtain the first processing result.

[0072] In an application, the exception type includes the first exception type. The first exception type refers to an exception that can be captured and handled by the exception handling logic of the asynchronous task itself, usually characterized as an exception of the Exception type. For example, when opening a file, if the requested file or directory does not exist, an exception of the FileNotFoundError type will be triggered. When performing a division operation, an exception of the ZeroDivisionError type may be encountered, etc. The first exception type represents an exception caused by an error condition. For such exceptions, when writing the asynchronous task, the occurrence of such exceptions has been foreseen, and special handling logic has been added to the code. This handling logic generally includes but is not limited to logging, notifying the user, rolling back transactions, retrying, etc. For example, if it is found that a certain parameter is invalid, the error information can be logged and an appropriate error response can be returned. Such a handling method helps to maintain the robustness of the program and can provide feedback to the user in a timely manner.

[0073] In an application, for the first exception type, the computer device can directly call the exception handling logic in the asynchronous task to perform exception handling to obtain the first processing result.

[0074] Step S103, if the exception type is the second exception type, perform exception handling based on the specified program to obtain the second processing result.

[0075] It should be noted that the first exception type represents an exception caused by an error condition, the second exception type represents an exception caused by stopping an asynchronous task, the specified program is an asynchronous framework program on which the asynchronous task depends, and the specified program encapsulates an exception handling logic for processing the second exception type.

[0076] In an application, the exception type can also include the second exception type. For an exception of the second exception type, the computer device cannot directly handle it through the exception handling logic of the asynchronous task itself, but needs to delegate it to the specified program for exception handling. If an exception of the second exception type is not handled, it usually directly causes the system to crash or the asynchronous task to block, and may also directly display error information containing technical terms and internal details to the user, resulting in a poor user experience. The second exception type usually represents an exception that is not of the Exception type, such as an exception caused by a keyboard interrupt event (KeyboardInterrupt), etc. When handling an exception of the second exception type, the asynchronous task needs to be forcibly stopped. To ensure the normal termination of the asynchronous task, when the computer device detects an exception of the second exception type, it directly passes the exception to the specified program for execution, so as to call the specified program to execute the exception handling for the second asynchronous type.

[0077] In an application, the specified program can be a module specifically used to handle such exceptions, or it can be an asynchronous framework program on which the asynchronous task depends. To reduce complexity, the specified program can directly be the asynchronous framework program. In this case, the computer device directly delegates an exception of the second exception type to the asynchronous framework program for processing. The asynchronous framework program is a software architecture design used to support concurrent processing and non-blocking operations. It allows the program to continue executing other tasks while waiting for certain operations (such as network requests, file I / O, etc.) to complete, thereby improving the performance and responsiveness of the application program, and is widely used in Web development, network programming, and any scenario that requires high-concurrency processing.

[0078] In an application, when the computer device captures an exception of the second exception type and delegates it to the specified program to handle the exception of the second exception type, it can effectively avoid the running crash of the asynchronous task and avoid directly exposing error information containing technical terms and internal details, so as to ensure a friendly exit of the asynchronous task.

[0079] In an application, the first exception type and the second exception type can inherit from the same exception base class. Exemplarily, in Python, all exception instances must be instances derived from the BaseException type. The exception base class is BaseException. The Exception type that inherits from the exception base class belongs to the first exception type, and the non-Exception type that inherits from the exception base class belongs to the second exception type, such as the SystemExit type, the KeyboardInterrupt type, and the CancelledError type described above.

[0080] In this embodiment, during the running of the asynchronous task, by identifying the exception type of the captured exception event, the source of the exception can be accurately located, and the first exception type caused by error conditions and the second exception type caused by stopping the asynchronous task can be distinguished. For the first exception type, the built-in exception handling logic is used to handle the exception to obtain the first handling result. For the second exception type, the asynchronous framework program is used to handle the exception to obtain the second handling result. In this way, the stability and reliability of the application program can be improved through differentiated exception handling methods.

[0081] In one embodiment, as Figure 3 shown, Figure 2 the implementation process of step S102 in

[0082] Step S201, obtain the error information of the exception event.

[0083] In an application, the first exception type also includes multiple subtypes, and different subtypes match different error information. Different exception handling strategies can be used for different subtypes. The computer device obtains the error information of the exception event of the first exception type. The error information includes multiple key features describing the exception event, such as the exception event name, the operation that caused the exception event, etc. For example, subtypes of the Exception type such as FileNotFoundError (raised when the requested file or directory does not exist) and IndexError (raised when the sequence extraction exceeds the range).

[0084] Step S202, based on the error information, match the target subtype from the multiple subtypes included in the first exception type.

[0085] In an application, the computer device identifies key features included in the error information, such as the exception event name, the operation that caused the exception event, etc., and matches the target subtype from the multiple subtypes included in the first exception type.

[0086] Step S203: Control the execution flow of the asynchronous task to transfer to the sub-exception handling logic adapted to the target subtype.

[0087] In an application, the computer device directly controls the execution flow of the asynchronous task to transfer to the sub-exception handling logic adapted to the target subtype, and performs exception handling for the corresponding subtype.

[0088] Step S204: Execute the sub-exception handling logic to obtain a first processing result.

[0089] In an application, the computer device executes the sub-exception handling logic to obtain a first processing result.

[0090] In this embodiment, by identifying the subtype of the exception event of the first exception type, the accuracy of the exception handling for the first exception type is achieved.

[0091] In one embodiment, as Figure 4 shown, Figure 2 the implementation process of step S103 in

[0092] Step S301: Determine the specified operation that triggers the exception event.

[0093] In an application, the exception event of the second exception type is usually triggered based on a specified operation. The exception event of the second exception type may include an exception event caused by a keyboard interrupt operation, an exception event caused by a cancel task execution operation, etc. After the computer device captures the exception event of the second exception type, it determines the specified operation that triggers the exception event. For example, during the execution of an asynchronous task, the computer device detects a keyboard interrupt operation corresponding to a keyboard interrupt event or a cancel task execution operation that triggers a cancel task event.

[0094] Step S302: Based on the specified program, perform a target operation for the asynchronous task to obtain a second processing result, where the second processing result indicates that the asynchronous task has terminated execution, and the target operation is adapted to the specified operation.

[0095] In an application, the computer device throws the exception of the second exception type to the specified program to perform a target operation for the asynchronous task based on the specified program. The target operation includes stopping the asynchronous task, releasing resources, etc.

[0096] In this embodiment, by delegating the exception handling of the second exception type to the exception framework program for execution, it can effectively avoid the running crash of the asynchronous task and avoid directly exposing error information containing technical terms and internal details, so as to ensure a friendly exit of the asynchronous task.

[0097] In one embodiment, based on Figure 2 asFigure 5 As shown in Figure 5 , the processing procedures for different exception events that trigger the second exception type are as follows:

[0098] Step S401: For a keyboard interrupt event, based on a specified program, directly interrupt the execution of the asynchronous task.

[0099] In an application, the exception events that trigger the second exception type may include keyboard interrupt events. A keyboard interrupt event is triggered by an input operation of a keyboard instruction. The exception type of the keyboard interrupt event is identified as the second exception type. For this exception type, based on a specified program, directly interrupt the execution of the asynchronous task.

[0100] In an application, interrupting task execution generally means that the asynchronous task immediately stops executing due to an external signal or an unforeseen event (such as a user operation like KeyboardInterrupt, which can be triggered by Ctrl+C). Such interruptions are usually sudden and not explicitly initiated through a programming interface. An interruption usually requires the asynchronous task to immediately stop executing, rather than waiting for the asynchronous task to end naturally or perform cleanup work. An interruption usually causes an exception to be thrown (such as KeyboardInterrupt).

[0101] For example, when running a long-running asynchronous task, if it is necessary to interrupt the program execution, usually the Ctrl+C key combination is pressed to send an interrupt signal to the computer device. In Python, this interrupt signal will be captured and trigger a KeyboardInterrupt exception. The computer device captures this exception and throws it to the asynchronous framework program that runs the asynchronous task to directly interrupt the execution of the asynchronous task based on the asynchronous framework program.

[0102] Step S402: For a cancellation execution event, based on a specified program, restore the resources whose operation has changed or been occupied due to the running of the asynchronous task, and terminate the execution of the asynchronous task.

[0103] In an application, the exception events also include cancellation execution events. A cancellation execution event is triggered by a cancellation task operation. The exception type of the cancellation execution event is identified as the second exception type. The specified operation is the cancellation task operation. For the exception handling of the cancellation execution event, the computer device, based on a specified program, restores the resources whose operation has changed or been occupied due to the running of the asynchronous task, and terminates the execution of the asynchronous task.

[0104] In an application, the operation of canceling an asynchronous task refers to actively requesting to terminate the task when the asynchronous task has not been completed yet. It is an operation that can be explicitly initiated through a programming interface and is usually executed by the initiator or management system of the asynchronous task. When a computer device catches an exception caused by a cancellation execution event (such as an exception of the CancelledError type), it passes the exception to the asynchronous framework program. Based on a specified program, it restores the resources whose operation has changed or been occupied based on the asynchronous task and terminates the execution of the asynchronous task. For example, in Python, when an exception occurs, the exception can be thrown through the raise statement.

[0105] In this implementation, by distinguishing between keyboard interrupt events and cancellation execution events and handling them in the ways of direct interruption and resource restoration plus termination respectively, it can not only ensure the stability of the asynchronous task operation but also simplify the exception handling logic.

[0106] In one embodiment, the exception type is an unknown exception type. Based on Figure 2 , such as Figure 6 shown, the exception handling process of the computer device further includes step S104:

[0107] Step S104, if the exception type is an unknown exception type, then based on a preset fixed error code and error message, generate an error response message, where the unknown exception type represents an exception type other than the first exception type and the second exception type.

[0108] In an application, the exception type can also be divided into known exception types and unknown exception types. Known exception types refer to those exceptions that may occur and for which handling logic has been written when writing the code. The first exception type and the second exception type belong to the known exception types. Unknown exception types usually refer to those error situations that are not within the expected range and are exception types other than the first exception type and the second exception type. For unknown exception types, exception handling is usually based on a preset fixed error code and the corresponding error message.

[0109] In this embodiment, by encapsulating the exception handling logic for unknown exception types, it can ensure that the asynchronous task can still continue to run when an unknown exception is encountered and give a reasonable error response instead of directly exposing the internal error information.

[0110] In one embodiment, the computer device (the server deploying the asynchronous task) can also perform corresponding exception handling on the asynchronous requests sent by the terminal device. Based on Figure 2 , such as Figure 7 shown, before step S101, the following step S501 is also executed:

[0111] Step S501, if an asynchronous request sent by a terminal device is received, then run an asynchronous task, where the asynchronous task is used to respond to the asynchronous request.

[0112] In an application, the triggering manner of an exception event can also be triggered during the process that a computer device (a server deploying an asynchronous task) runs an asynchronous task to respond to an asynchronous request from a terminal device. Specifically, a terminal device communicating with the computer device sends an asynchronous request to the computer device, and the computer device runs an adapted asynchronous task to respond to the asynchronous request.

[0113] During the process of responding to an asynchronous request based on an asynchronous task, if an exception event is triggered, the computer device can implement corresponding exception handling based on the foregoing exception handling method. The exception handling for an asynchronous request is as described above and will not be elaborated here. After the computer device processes the exception event, it can also execute Step S502 to Step S503:

[0114] Step S502, encapsulate the first processing result in a preset format to obtain an encapsulation result.

[0115] In an application, after obtaining the first processing result, the computer device can encapsulate the first processing result in a preset format. The encapsulation result has a standardized exception format, such as returning a JSON-format encapsulation result.

[0116] In an application, the encapsulation processing for the first processing result can also be implemented through a response middleware. The response middleware is a software component used to process and modify the response object of an application program. In the request-response cycle, the response middleware can perform operations before the final response is returned to the client, such as adding header information, compressing response data, logging, etc.

[0117] Step S503, use the encapsulation result as the response information for the asynchronous request, feedback it to the terminal device and display it.

[0118] In an application, the computer device uses the encapsulation result as the response information for the asynchronous request and returns it to the terminal device so that the response information can be displayed on the terminal device in a preset manner, such as a message prompt box, etc.

[0119] In this embodiment, the encapsulation processing for the exception handling result can make the responses of different APIs consistent, provide friendly error messages, and facilitate developers to understand and identify the reasons for exceptions.

[0120] In one embodiment, as Figure 8 shown, the exception handling process based on a global exception handler includes the following Step S601 to Step S602. Among them:

[0121] Step S601: Register a global exception handler in the running environment of the asynchronous task.

[0122] In an application, the computer device can also perform exception handling based on the global exception handler. The global exception handler references a unified processing mechanism in the business layer of the asynchronous framework so as to be able to capture exceptions thrown in different modules, functions, or methods.

[0123] Step S602: Execute the exception handling process for the exception event through the global exception handler.

[0124] In an application, the computer device can implement exception handling for the exception type based on any one of the exception handling methods as Figures 2 to 7 shown, and the specific processing process will not be elaborated here.

[0125] It should be noted that the global exception handler can also call the response middleware to provide adapted response information for different exception types.

[0126] In this embodiment, the global exception handler can provide a unified exception handling mechanism to centrally handle various possible exception situations, enhancing the robustness and maintainability of the application program. It can ensure consistent error handling behavior throughout the application program.

[0127] In one embodiment, taking the exception handling method provided in this application being applied to a scenario where the front-end and back-end are separated in a Web service and services in a microservice architecture call each other through an application programming interface (API) as an example for illustration, as Figure 8 shown, the front-end request is sent to the back-end server through the gateway service. The back-end server runs the corresponding asynchronous task through the business processing module to respond to the front-end request for business processing. During the asynchronous task processing, the server captures an exception event and centrally processes various possible exception situations according to the aforementioned exception handling process by calling the global exception handler registered in the running environment, and provides a corresponding error response to ensure that friendly error information is fed back to the front-end.

[0128] After obtaining the exception handling result, it is also possible to combine the response middleware to implement the recording of relevant logs for the exception. Specifically, before feeding back the response result to the front-end request, it is determined whether an exception has occurred based on the response middleware. If there is an exception, the exception information will be recorded in the log storage system. It can effectively track and analyze the behavior and state of the application program during operation.

[0129] Based on Figure 9 , the implementation process of performing exception handling for the exception captured during the process of responding to the front-end request is as Figure 10As shown, the server receives a front-end request and runs an asynchronous task adapted to the front-end request. During the execution of the asynchronous task, it determines whether an exception event is captured. If not, it directly returns the response result for the front-end request. If an exception event is captured, it calls the global exception handling to execute the following exception handling process: It determines whether the exception type of the exception event is a known exception type. If so, it further determines whether it is a keyboard interrupt exception in the second exception type. If it is, it throws it to a specified program for exception handling based on the specified program. If it is not a keyboard interrupt exception, it continues to determine whether it is a CancelledError (task cancellation exception). If it is, it throws it to a specified program for exception handling based on the specified program. If not, it is identified as the first exception type and corresponding exception handling is performed to obtain the first processing result. Finally, it calls the response middleware to standardize the exception handling result to obtain a response message in a preset format and feedback it to the terminal device that sent the front-end request.

[0130] The exception handling method implemented in this embodiment can cover a wide range of exception types, providing more comprehensive protection. At the same time, it can efficiently and uniformly manage various exception situations. It effectively encapsulates the exception handling logic for different exception types, reducing code redundancy, while improving the readability and maintainability of the code. At the same time, it can uniformly handle and return friendly error messages to users, ensuring the stability and reliability of the application.

[0131] This application embodiment also provides an exception handling device for executing the steps in the above-mentioned exception handling method embodiment. As Figure 11 shown, the exception handling control device 1000 provided in this application embodiment includes:

[0132] An identification module 1010, configured to identify an exception caused by an exception event during the execution of an asynchronous task to obtain an exception type;

[0133] A first processing module 1020, configured to, if the exception type is the first exception type, perform exception handling based on the exception handling logic in the asynchronous task to obtain a first processing result.

[0134] A second processing module 1030, configured to, if the exception type is the second exception type, perform exception handling based on a specified program to obtain a second processing result.

[0135] Wherein, the first exception type represents an exception caused by an error condition, the second exception type represents an exception that stops the asynchronous task, and the specified program is an asynchronous framework program on which the asynchronous task depends.

[0136] In one embodiment, the first processing module is further configured to obtain the error information of the exception event; based on the error information, match the target subtype from the multiple subtypes included in the first exception type; control the execution flow of the asynchronous task to transfer to the sub-exception handling logic adapted to the target subtype; execute the sub-exception handling logic to obtain the first processing result.

[0137] In one embodiment, the second processing module is further configured to determine the specified operation that causes the exception event; based on the specified program, execute the target operation for the asynchronous task to obtain the second processing result, where the second processing result indicates that the asynchronous task has terminated execution, and the target operation is adapted to the specified operation.

[0138] In one embodiment, the exception event includes a keyboard interrupt event, which is triggered based on the input operation of a keyboard instruction. The exception type of the keyboard interrupt event is identified as the second exception type, and the specified operation is the input operation of the keyboard instruction. The second processing module is further configured to directly interrupt the execution of the asynchronous task based on the specified program.

[0139] In one embodiment, the exception event includes a cancellation execution event, which is triggered based on a cancel task operation. The exception type of the cancellation execution event is identified as the second exception type, and the specified operation is the cancel task operation. The second processing module is further configured to restore the resources whose operation has changed or been occupied based on the asynchronous task and terminate the execution of the asynchronous task based on the specified program.

[0140] In one embodiment, the processing module is further configured to, if the exception type is an unknown exception type, generate an error response message based on a preset fixed error code and the error information; where the unknown exception type represents an exception type other than the first exception type and the second exception type.

[0141] In one embodiment, the recognition module is further configured to, if an asynchronous request sent by the terminal device is received, run an asynchronous task, where the asynchronous task is used to respond to the asynchronous request.

[0142] In one embodiment, if the exception type is the first exception type, the processing module is further configured to encapsulate the first processing result in a preset format to obtain an encapsulation result; use the encapsulation result as the response message of the asynchronous request, and feedback it to the terminal device for display.

[0143] In one embodiment, the recognition module is further configured to register a global exception handler in the running environment of the asynchronous task; where the global exception handler encapsulates the exception handling strategies of each exception type, and the global exception handler is used to implement the exception handling method of any one of the present application.

[0144] In an application, each module in the exception handling device can be a software program module, can also be implemented by different logic circuits integrated in a processor, or can also be implemented by multiple distributed processors.

[0145] Figure 12 The following is a schematic structural diagram of a computer device for implementing an exception handling method provided by an embodiment of the present application. As Figure 12 shown, the computer device 1100 of this embodiment includes: at least one processor 1110 ( Figure 12 only one is shown in the figure), a processor, a memory 1120, and a computer program 1130 stored in the memory 1120 and executable on the at least one processor 1110. When the processor 1110 executes the computer program 1130, the steps in any of the above-mentioned exception handling method embodiments are implemented.

[0146] The computer device 1100 may be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The computer device 1100 may include, but is not limited to, a processor 1110 and a memory 1120. Those skilled in the art can understand that Figure 11 merely examples of the computer device 1100 are provided and do not constitute a limitation on the computer device 1100. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0147] The so-called processor 1110 may be a central processing unit (CPU). The processor 1110 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0148] In some embodiments, the memory 1120 may be an internal storage unit of the computer device 1100, such as the hard disk or memory of the computer device 1100. In other embodiments, the memory 1120 may also be an external storage device of the computer device 1100, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the computer device 1100. Further, the memory 1120 may also include both the internal storage unit and the external storage device of the computer device 1100. The memory 1120 is used to store an operating system, application programs, a BootLoader, data, and other programs, such as the program code of the computer program. The memory 1120 may also be used to temporarily store data that has been output or will be output.

[0149] It should be noted that for the information interaction, execution process, etc. between the above-mentioned device / units, since they are based on the same concept as the method embodiments of the present application, for their specific functions and the technical effects brought, reference can be specifically made to the method embodiment part, and details will not be repeated here.

[0150] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of the present application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiments and will not be repeated here.

[0151] The embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0152] The embodiment of the present application provides a computer program product. When the computer program product runs on a mobile terminal, the mobile terminal can execute to implement the steps in the above-mentioned method embodiments.

[0153] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-described embodiment methods of this application, a computer program can be used to instruct relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-described various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the device / terminal device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk, or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium cannot be an electrical carrier signal and a telecommunication signal.

[0154] In the above embodiments, the descriptions of the various embodiments each have their own focuses. For parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0155] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or by a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of this application.

[0156] In the embodiments provided in this application, it should be understood that the disclosed device / network device and method can be implemented in other ways. For example, the device / network device embodiments described above are only illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical, or other form.

[0157] The unit described as a separating component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or may be distributed over multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0158] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An exception handling method, characterized in that, The method includes: During the running of the asynchronous task, identifying an exception caused by an exception event to obtain an exception type; If the exception type is the first exception type, performing exception handling based on the exception handling logic in the asynchronous task to obtain a first processing result; If the exception type is the second exception type, performing exception handling based on a specified program to obtain a second processing result; Wherein, the first exception type represents an exception caused by an error condition, the second exception type represents an exception that stops the asynchronous task, and the specified program is an asynchronous framework program on which the asynchronous task depends.

2. The exception handling method according to claim 1, wherein The performing exception handling based on the exception handling logic in the asynchronous task to obtain a first processing result includes: Obtaining the error information of the exception event; Based on the error information, matching a target subtype from multiple subtypes included in the first exception type; Controlling the execution flow of the asynchronous task to transfer to a sub-exception handling logic adapted to the target subtype; Executing the sub-exception handling logic to obtain a first processing result.

3. The exception handling method according to claim 1, wherein The performing exception handling based on a specified program to obtain a second processing result includes: Determining a specified operation that causes the exception event; Based on the specified program, performing a target operation on the asynchronous task to obtain a second processing result, where the second processing result represents that the asynchronous task has terminated execution, and the target operation is adapted to the specified operation.

4. The exception handling method according to claim 3, characterized in that, The exception event includes a keyboard interrupt event, the keyboard interrupt event is triggered based on an input operation of a keyboard instruction, and the exception type of the keyboard interrupt event is identified as the second exception type, The specified operation is the input operation of the keyboard instruction, and the performing a target operation on the asynchronous task based on the specified program includes: Directly interrupting the execution of the asynchronous task based on the specified program.

5. The exception handling method according to claim 3, characterized in that The exception event includes a cancellation execution event, the cancellation execution event is triggered based on a task cancellation operation, and the exception type of the cancellation execution event is identified as the second exception type, The specified operation is the task cancellation operation, and the performing a target operation on the asynchronous task based on the specified program includes: Based on the specified program, restoring resources that have changed or been occupied due to the running of the asynchronous task, and terminating the execution of the asynchronous task.

6. The exception handling method according to claim 1, wherein The method further includes: If the exception type is an unknown exception type, generating error response information based on a preset fixed error code and error information; Wherein, the unknown exception type represents an exception type other than the first exception type and the second exception type.

7. The exception handling method according to claim 1, wherein Before the identifying an exception caused by an exception event to obtain an exception type during the running of the asynchronous task, the method further includes: If an asynchronous request sent by a terminal device is received, running the asynchronous task, where the asynchronous task is used to respond to the asynchronous request; When the exception type is the first exception type, the method further includes: Encapsulating the first processing result in a preset format to obtain an encapsulation result; Use the encapsulation result as the response information of the asynchronous request, and feedback it to the terminal device for display.

8. The exception handling method according to any one of claims 1 to 7, characterized in that, Before identifying the exception type of the captured exception event, the method further includes: Register a global exception handler in the running environment of the asynchronous task; Wherein, the global exception handler encapsulates the exception handling strategy for each exception type, and the global exception handler is used to implement the method described in any one of claims 1-7.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, the computer device is enabled to implement the method described in any one of claims 1-8.

10. A computer program product, characterized in that, It includes a computer program, and when the computer program is run, the method described in any one of claims 1-8 is executed.