Abnormality processing method and device, equipment and storage medium
By passing standardized exception information between application systems, the problem of the inability to transmit exception information caused by the separation of the distributed tracking system and the data storage of the business system is solved, and the consistency and readability of the exception information transmission between business systems is achieved.
Patent Information
- Application Number
- CN202411720276.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-27
- Publication Date
- 2025-04-08
AI Technical Summary
The distributed tracking system and the data storage of the business system are separated from each other, causing the business system to be unable to access and obtain detailed Trace Ids and call chain information recorded by the tracking system, thus unable to obtain clear exception information and display clear exception prompt information to users.
By determining multiple application systems required to complete the current business operations and passing exception information between application systems, including exception status codes and exception information descriptions, ensure that the transmission of exception information between business systems is consistent and readable.
It realizes the standardized transmission of exception information between business systems, ensuring that no matter which node the exception occurs, the exception-related information can be accurately passed to the upstream and downstream systems, thus solving the problem that the business system cannot obtain effective exception information.
Smart Images

Figure CN119782014A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of data processing technology, and in particular to an exception handling method, device, equipment and storage medium. Background Art
[0002] Exceptions are inevitable during software development. When developers handle various exceptions, they need to handle them properly according to the business to ensure that the user is accurately informed of the cause of the system exception, give the user clear suggestions, and improve the user experience. When there are complex long-link call relationships between multiple systems, how to quickly locate where the fault occurs in the link is the prerequisite for quickly solving the problem.
[0003] At present, distributed tracing systems are usually introduced from the perspective of operation and maintenance monitoring to quickly locate where the fault occurs in the link. These distributed tracing systems can track requests and responses across multiple services and record related logs and exception information. At the same time, a unique Trace Id (tracing identifier) and Span Id (span identifier) are generated in each request to identify the entire scheduling link and each service call therein. These IDs will be transmitted along with the request throughout the call link, so that exceptions in any link can be tracked and located.
[0004] Although the above-mentioned distributed tracing system, i.e., call chain monitoring, is introduced from the operation and maintenance perspective to support the operation and maintenance team to quickly locate problems, the data storage of the distributed tracing system and the business system are separated from each other, and there is a lack of direct data channels or interfaces between the two to share and transfer information. Therefore, even if the tracing system records detailed Trace Id and call chain information, it is difficult for the business system to directly access and obtain this data, and thus it is impossible to display clear abnormal prompt information to users. Summary of the invention The embodiments of the present disclosure provide an exception handling method, apparatus, device and storage medium to solve the problem in the related art that due to the separation of data storage between a distributed tracing system and a business system, the business system cannot access and obtain detailed Trace Id and call chain information recorded by the tracing system, thereby making it impossible for the business system to obtain clear exception information and display clear exception prompt information to the user.
[0005] In a first aspect, an embodiment of the present disclosure provides an exception handling method, the method comprising: Determine the multiple application systems that need to be called to complete the current business operation; For any of the application systems, if an exception is generated by itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status code is determined, and the exception information is sent to its upstream application system when called; wherein the exception status code is determined according to a pre-set exception status code encoding rule, and the exception status code encoding rule is to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception; the exception information is generated according to a pre-set standard exception information field; the standard exception information field includes at least one of the following: an exception status code, an exception information description, an exception error node and port, an exception error information stack, and an interface uniform resource locator URL where the exception is generated.
[0006] In a second aspect, an embodiment of the present disclosure provides an exception handling device, the device comprising: A determination module is used to determine multiple application systems that need to be called to complete the current business operation; A processing module is used for determining, for any of the application systems, exception information including an exception status code if the application system itself generates an exception or detects an exception in the process of calling a downstream application system, and sending the exception information to its upstream application system when called; wherein the exception status code is determined according to a preset exception status code encoding rule, and the exception status code encoding rule is to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception; the exception information is generated according to a preset standard exception information field; the standard exception information field includes at least one of the following: an exception status code, an exception information description, an exception error node and port, an exception error information stack, and an interface uniform resource locator URL that generates the exception.
[0007] In a third aspect, an embodiment of the present disclosure provides an exception handling device, comprising: a processor; and a memory configured to store computer executable instructions, wherein the computer executable instructions, when executed, enable the processor to implement the steps of the method described in the first aspect above.
[0008] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store computer-executable instructions, and the computer-executable instructions implement the steps of the method described in the first aspect when executed by a processor.
[0009] In a fifth aspect, an embodiment of the present disclosure provides a computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the method described in the first aspect are implemented.
[0010] At least one of the above technical solutions provided by the embodiments of the present invention can achieve the following technical effects: In the embodiment of the present invention, multiple application systems that need to be called when completing the current business operation can be determined first, and then, for any application system, if an exception occurs in itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status code can be determined, and the exception information is sent to its upstream application system when it is called. Among them, the exception information and the exception status code are generated according to the pre-set rules.
[0011] It can be seen from the above content that in the embodiment of the present invention, when an exception occurs or is detected, the exception status code and exception information can be determined according to the pre-set detailed rules, so that standard and unified exception information and exception status code can be obtained, and then the obtained standard and unified exception information and exception status code can be transmitted. This standard and unified format can make the transmission of exception information between business systems consistent and readable. No matter which node the exception occurs, the exception-related information can be accurately transmitted to the upstream and downstream systems according to the established rules, thereby making up for the insufficiency of the business system in the related technology that cannot obtain effective exception information, and effectively solving the problem that the business system cannot access and obtain the detailed TraceId and call chain information recorded by the tracking system due to the separation of the data storage of the distributed tracking system and the business system in the related technology, so that the business system cannot obtain clear exception information, and cannot display clear exception prompt information to the user. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In order to more clearly illustrate one or more embodiments of the present disclosure or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative labor. Figure 1 One of the flowcharts of the exception handling method provided by one embodiment of the present invention; Figure 2 A second flowchart of an exception handling method provided by an embodiment of the present invention; Figure 3 A third flowchart of an exception handling method provided by an embodiment of the present invention; Figure 4 A schematic diagram of the module composition of an exception handling device 400 provided in one embodiment of the present invention; Figure 5 A schematic diagram of the hardware structure of an exception handling device provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0013] In order to make the technical parties in this technical field better understand the technical aspects of one or more embodiments of the present disclosure, and to make the purpose, technical solutions and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in combination with the specific embodiments of the present invention and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.
[0014] The technical solutions provided by various embodiments of the present invention are described in detail below in conjunction with the accompanying drawings.
[0015] See also Figure 1 , Figure 1 One of the flow charts of the exception handling method provided by one embodiment of the present invention is as follows: Figure 1 As shown, the method comprises the following steps: Step 102: Determine multiple application systems that need to be called to complete the current business operation.
[0016] Step 104: For any application system, if it generates an exception itself, or detects an exception in the process of calling a downstream application system, the exception information including the exception status code is determined, and the exception information is sent to its upstream application system when called; wherein, the exception status code is determined according to a pre-set exception status code encoding rule, and the exception status code encoding rule is to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception; the exception information is generated according to a pre-set standard exception information field; the standard exception information field includes at least one of the following: an exception status code, an exception information description, an exception error node and port, an exception error information stack, and an interface URL that generates the exception.
[0017] In the embodiment of the present invention, when a user performs a business operation, multiple application systems that need to be called to complete the current business operation can be determined.
[0018] For example, when a user wants to perform a car insurance quotation business operation through the front end of an insurance APP, the insurance APP needs to call the backend system corresponding to the insurance APP, the backend system needs to call the car insurance underwriting system, and the car insurance underwriting system needs to call the car insurance pricing system in order to obtain the car insurance quotation. Therefore, it can be determined that the multiple application systems required to complete the business operation are: the backend system corresponding to the insurance APP, the car insurance underwriting system, and the car insurance pricing system.
[0019] After determining multiple application systems that need to be called, for any application system, if an exception occurs in itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status can be determined, wherein the exception status code is determined according to a pre-set exception status code encoding rule, and the exception status code encoding rule can be used to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception, and the exception information is generated according to a pre-set standard exception information field, and the standard exception information field can include at least one of the following: exception status code, exception information description, exception error node and port, exception error information stack, and interface URL (uniform resource locator) that generates the exception.
[0020] In the embodiment of the present invention, if the application system itself generates an exception, the exception can be encoded according to a preset exception status code encoding rule to determine the exception status code corresponding to the exception.
[0021] Among them, the pre-set abnormal status code encoding rules can be: First, the first-level status code is set according to the source corresponding to the exception, where the source can include at least one of the following: user end, current application system, upstream call system internal interface, upstream call system external third-party interface.
[0022] For example, the abnormal source can be coded using U, S, I, and E according to different sources and placed at the first place in the code.
[0023] Table 1
[0024] Then, the second-level status code can be set according to the type of exception, so as to further divide the type of exception under the first-level category of different exception sources. Among them, the type of exception can include at least one of the following: parameter exception, permission exception, operation exception, business logic exception, null pointer / array out-of-bounds exception, network connection exception, database exception, file IO exception, cache exception, message queue exception, unknown exception.
[0025] For example, the code for the type corresponding to the exception can be a 2-digit number, placed in the second and third digits of the code.
[0026] Table 2
[0027] The third-level status code can be determined based on the business type corresponding to the exception, that is, the relevant business link corresponding to the scenario of the application exception. For example, when an exception occurs in multiple application systems called when the above-mentioned user wants to perform a car insurance quotation business operation through the front end of the insurance APP, the business type corresponding to the exception can be determined as a car insurance quotation.
[0028] Then, the application status code can be determined according to the occurrence scenario corresponding to the exception, wherein the occurrence scenario can include at least one of the following: interface module, microservice, front-end page, application system. And according to the preset exception status code format, the first-level status code, the second-level status code, the third-level status code and the application status code can be combined in order to obtain the exception status code.
[0029] For example, the format of the exception status code can be a 7-digit string + application code, and the 7-digit string can be in the format of: 1-digit exception source + 2-digit exception type + 4-digit business type. Among them, the first 3 digits are predefined codes, and the last 4 digits are codes determined according to the business type. The application code can be the application code in the architecture management platform, including: interface module code, microservice code, front-end page code, application system code, etc. The 7-digit code and the application system code can be connected with a hyphen "-".
[0030] After determining the abnormal status code, the abnormal information including the abnormal status code can be determined. The abnormal information can be generated according to a preset standard abnormal information field, and the standard abnormal information field can include at least one of the following: abnormal status code, abnormal information description, abnormal error reporting node and port, abnormal error reporting information stack, and interface URL generating the abnormality.
[0031] After determining the exception information containing the exception status code, the current application system can write the exception information into the log to record the exception information in detail. The log can be transmitted and accumulated during the scheduling process between multiple application systems, so that the subsequent upstream application system can obtain the propagation path of the exception information in the entire link and related context information from the log, without relying on the Trace Id or call chain information provided separately by the distributed tracing system, which solves the problem of information disconnection between the business system and the distributed tracing system in related technologies.
[0032] In the embodiment of the present invention, in the scenario of multi-level application system calls, each node in the call chain must write the exception code and exception information into the interface return message body in the standard exception information field to ensure the continuity of exception information transmission.
[0033] For any of the application systems, if an exception is detected during the process of calling a downstream application system, exception information including an exception status code may be determined.
[0034] Among them, when the downstream application system is successfully called, the exception information containing the exception status code in the interface return message fed back by the downstream application system can be obtained; and when the downstream application system is not successfully called, in the pre-set exception handling module, according to the pre-set exception status code encoding rules and the pre-set standard exception information field, the exception information containing the exception status code is generated.
[0035] In one embodiment of the invention, Figure 2 As shown, if the current application system calls the downstream interface as the caller, and the HTTP status code in the interface return message received by the caller is 200 or other status code indicating a successful call (for example, 304), if the message carries an abnormal status code, the abnormal information including the abnormal code in the message can be directly obtained and logged.
[0036] Among them, if the exception occurs during the application system call process, the exception information including the exception status code can be transmitted to its upstream application system when it is called; if the exception occurs when it is called by the front-end page, it can be determined whether the preset escape condition is met, and if the preset escape condition is met, the exception information is first escaped, and then the escaped exception information is sent to the front-end page, wherein the escape condition can be that the accuracy of the expression of the exception information meets the preset accuracy requirement.
[0037] When the exception information including the exception status code is transparently transmitted to its upstream application system, the exception error node and port field in the exception information can be replaced with the node IP and port number of the current application system, and connected in series in front of the exception error information stack to obtain the replaced exception information, and then the replaced exception information is sent to its upstream application system. The rest of the information can be transmitted as it is.
[0038] Considering that the expression of abnormal information may have the problem of low accuracy, for example, when the corresponding technical personnel lack description experience, the expression of abnormal information is large and the accuracy is low, or when the existing model that does not match the abnormal information model scenario is used to automatically express the abnormal information, there may be a problem of low accuracy in the expression of abnormal information. At this time, the abnormal information can be escaped.
[0039] When escaping the exception information, the exception status code, exception information description, exception error node and port, and exception error information stack in the exception information can be taken out and updated, and then the updated exception status code, exception information description, exception error node and port, and exception error information stack are spliced to obtain the escaped exception information.
[0040] The escaped exception information can more clearly describe the cause of the problem and try to control the length of the exception information description. For errors returned to the front end for display, code-level error information can be avoided to ensure that users can understand it.
[0041] It should be noted that during the transmission of exception information, the following scenarios all require exception information escaping: 1. If the module with interface call exception fails to successfully receive exception information from the upstream system, it needs to be escaped.
[0042] 2. When a module where an interface call exception occurs is touched by a front-end user, if the downstream exception information is received, it may be inaccurately expressed and needs to be escaped.
[0043] 3. If the upstream abnormal information cannot be accurately expressed and may cause misunderstanding, it needs to be escaped.
[0044] From the above content, we can see that Figure 3 As shown, when scheduling is performed between multiple application systems, each application system focuses on the exceptions that may be generated by the application system, handles various exceptions generated by the application system, and processes and transmits exception information to the downstream in the interface call scenario, and performs exception encoding and escape of exception information when necessary.
[0045] In one embodiment of the invention, Figure 2 As shown, if the current application system calls the downstream interface as the caller, and the HTTP status code in the interface return message received by the caller is a call failure status (for example, 404, 500, etc.), or the caller does not receive an interface response message, then exception handling should be performed in the corresponding module, such as a pre-set exception handling module. The exception handling module can generate exception information containing the exception status code according to the pre-defined exception status code encoding rules and standard exception information fields shown above, and record it in the log.
[0046] At the same time, when such an exception occurs when the caller is called by the upstream system, the exception information can be written into the return message to the upstream system to ensure the clarity and comprehensibility of the information when it is returned to the front end.
[0047] In an embodiment of the present invention, when an application system records abnormal information in a log, it can record according to a preset recording format to maintain a uniform log format, making it easier for an upstream application system to obtain a propagation link of the abnormal information based on the recorded log.
[0048] In an embodiment of the present invention, the exception status code may not be actively displayed to the user. If the exception status code is indeed needed, or if the fault needs to be reported to operation and maintenance quickly, an "abnormal information report" button can be added to the page. When the user clicks it, the page can be redirected to the reporting page with the abnormal information, and the abnormal information can be carried.
[0049] In the embodiment of the present invention, multiple application systems that need to be called when completing the current business operation can be determined first, and then, for any application system, if an exception occurs in itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status code can be determined, and the exception information is sent to its upstream application system when it is called. Among them, the exception information and the exception status code are generated according to the pre-set rules.
[0050] It can be seen from the above content that in the embodiment of the present invention, when an exception occurs or is detected, the exception status code and exception information can be determined according to the pre-set detailed rules, so that standard and unified exception information and exception status code can be obtained, and then the obtained standard and unified exception information and exception status code can be transmitted. This standard and unified format can make the transmission of exception information between business systems consistent and readable. No matter which node the exception occurs, the exception-related information can be accurately transmitted to the upstream and downstream systems according to the established rules, thereby making up for the insufficiency of the business system in the related technology that cannot obtain effective exception information, and effectively solving the problem that the business system cannot access and obtain the detailed TraceId and call chain information recorded by the tracking system due to the separation of the data storage of the distributed tracking system and the business system in the related technology, so that the business system cannot obtain clear exception information, and cannot display clear exception prompt information to the user.
[0051] Corresponding to the above exception handling method, an embodiment of the present invention further provides an exception handling device, Figure 4 A schematic diagram of the module composition of the exception handling device 400 provided in an embodiment of the present invention is shown in FIG. Figure 4 As shown, the exception handling device 400 includes: Determination module 401, used to determine multiple application systems that need to be called when completing the current business operation; The processing module 402 is used for determining the exception information including the exception status code for any of the application systems, if the application system generates an exception itself, or detects an exception in the process of calling a downstream application system, and sending the exception information to its upstream application system when called; wherein the exception status code is determined according to a pre-set exception status code encoding rule, and the exception status code encoding rule is to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception; the exception information is generated according to a pre-set standard exception information field; the standard exception information field includes at least one of the following: an exception status code, an exception information description, an exception error node and port, an exception error information stack, and an interface uniform resource locator URL that generates the exception.
[0052] Optionally, the processing module 402 is used to: In the case of successful call to the downstream application system, the exception information including the exception status code in the interface return message fed back by the downstream application system is obtained; and in the case of unsuccessful call to the downstream application system, in the pre-set exception handling module, according to the pre-set exception status code encoding rules and the pre-set standard exception information field, the exception information including the exception status code is generated.
[0053] Optionally, the processing module 402 is used to: If an exception occurs during an application system call, the exception information including the exception status code will be transparently transmitted to its upstream application system when it is called; If an exception occurs when being called by the front-end page, it is determined whether the preset escape condition is met, and if the preset escape condition is met, the exception information is first escaped, and then the escaped exception information is sent to the front-end page; wherein the escape condition is that the expression accuracy of the exception information meets the preset accuracy requirement.
[0054] Optionally, the processing module 402 is used to: Replace the abnormal error node and port field in the abnormal information with the node IP and port number of the current application system, and connect them in series in front of the abnormal error information stack to obtain the replaced abnormal information; The replaced abnormal information is sent to its upstream application system.
[0055] Optionally, the processing module 402 is used to: The exception status code, exception information description, exception error reporting node and port, and exception error reporting information stack in the exception information are taken out and updated; The updated exception status code, exception information description, exception error reporting node and port, and exception error reporting information stack are concatenated to obtain the escaped exception information.
[0056] Optionally, the abnormal status code encoding rules include: According to the source corresponding to the exception, the first-level status code is set; the source includes at least one of the following: the user end, the current application system, the internal interface of the upstream calling system, and the external third-party interface of the upstream calling system; According to the type of exception, set the second-level status code; the type includes at least one of the following: parameter exception, permission exception, operation exception, business logic exception, null pointer / array out-of-bounds exception, network connection exception, database exception, file IO exception, cache exception, message queue exception, unknown exception; Determine the third-level status code based on the business type corresponding to the exception; Determine the application status code according to the occurrence scenario corresponding to the exception; the occurrence scenario includes at least one of the following: interface module, microservice, front-end page, application system; According to a preset abnormal status code format, the first-level status code, the second-level status code, the third-level status code and the application status code are combined in order to obtain an abnormal status code.
[0057] In the embodiment of the present invention, multiple application systems that need to be called when completing the current business operation can be determined first, and then, for any application system, if an exception occurs in itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status code can be determined, and the exception information is sent to its upstream application system when it is called. Among them, the exception information and the exception status code are generated according to the pre-set rules.
[0058] It can be seen from the above content that in the embodiment of the present invention, when an exception occurs or is detected, the exception status code and exception information can be determined according to the pre-set detailed rules, so that standard and unified exception information and exception status code can be obtained, and then the obtained standard and unified exception information and exception status code can be transmitted. This standard and unified format can make the transmission of exception information between business systems consistent and readable. No matter which node the exception occurs, the exception-related information can be accurately transmitted to the upstream and downstream systems according to the established rules, thereby making up for the insufficiency of the business system in the related technology that cannot obtain effective exception information, and effectively solving the problem that the business system cannot access and obtain the detailed TraceId and call chain information recorded by the tracking system due to the separation of the data storage of the distributed tracking system and the business system in the related technology, so that the business system cannot obtain clear exception information, and cannot display clear exception prompt information to the user.
[0059] Corresponding to the above exception handling method, an embodiment of the present invention further provides an exception handling device, Figure 5 A schematic diagram of the hardware structure of an exception handling device provided by an embodiment of the present invention.
[0060] The exception handling device may be a terminal device or a server for handling exceptions provided in the above-mentioned embodiment.
[0061] The exception handling device may have relatively large differences due to different configurations or performances, and may include one or more processors 501 and memory 502, and the memory 502 may store one or more storage applications or data. Among them, the memory 502 may be a short-term storage or a persistent storage. The application stored in the memory 502 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the exception handling device. Furthermore, the processor 501 may be configured to communicate with the memory 502, and execute a series of computer executable instructions in the memory 502 on the exception handling device. The exception handling device may also include one or more power supplies 503, one or more wired or wireless network interfaces 504, one or more input and output interfaces 505, and one or more keyboards 506.
[0062] Specifically in this embodiment, the exception handling device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer executable instructions in the exception handling device, and is configured to be executed by one or more processors.
[0063] In the embodiment of the present invention, multiple application systems that need to be called when completing the current business operation can be determined first, and then, for any application system, if an exception occurs in itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status code can be determined, and the exception information is sent to its upstream application system when it is called. Among them, the exception information and the exception status code are generated according to the pre-set rules.
[0064] It can be seen from the above content that in the embodiment of the present invention, when an exception occurs or is detected, the exception status code and exception information can be determined according to the pre-set detailed rules, so that standard and unified exception information and exception status code can be obtained, and then the obtained standard and unified exception information and exception status code can be transmitted. This standard and unified format can make the transmission of exception information between business systems consistent and readable. No matter which node the exception occurs, the exception-related information can be accurately transmitted to the upstream and downstream systems according to the established rules, thereby making up for the insufficiency of the business system in the related technology that cannot obtain effective exception information, and effectively solving the problem that the business system cannot access and obtain the detailed TraceId and call chain information recorded by the tracking system due to the separation of the data storage of the distributed tracking system and the business system in the related technology, so that the business system cannot obtain clear exception information, and cannot display clear exception prompt information to the user.
[0065] Another embodiment of the present disclosure further provides a computer-readable storage medium, where the computer-readable storage medium is used to store computer-executable instructions, and the computer-executable instructions implement the above process when executed by a processor.
[0066] The storage medium in the embodiment of the present disclosure can implement each process of the above-mentioned exception handling method embodiment and achieve the same effect and function, which will not be repeated here.
[0067] Another embodiment of the present disclosure further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the above process is implemented.
[0068] The computer program product in the embodiment of the present disclosure can implement each process of the above-mentioned exception handling method embodiment and achieve the same effect and function, which will not be repeated here.
[0069] In various embodiments of the present disclosure, the computer-readable storage medium includes a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.
[0070] In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented with a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.
[0071] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.
[0072] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
[0073] For the convenience of description, the above devices are described in terms of functions and are divided into various units. Of course, when implementing the embodiments of the present disclosure, the functions of each unit can be implemented in the same or multiple software and / or hardware.
[0074] It should be understood by those skilled in the art that one or more embodiments of the present disclosure may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, one or more embodiments of the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0075] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0076] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0077] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0078] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.
[0079] One or more embodiments of the present disclosure may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present disclosure may also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.
[0080] Each embodiment in the present disclosure is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.
[0081] The above description is only an embodiment of the present disclosure and is not intended to limit the present disclosure. For those skilled in the art, the present disclosure may have various changes and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the scope of the claims of the present disclosure.
Claims
1. An exception handling method, characterized in that: The method comprises: Determine the multiple application systems that need to be called to complete the current business operation; For any of the application systems, if an exception is generated by itself, or an exception is detected in the process of calling a downstream application system, the exception information including the exception status code is determined, and the exception information is sent to its upstream application system when called; wherein the exception status code is determined according to a pre-set exception status code encoding rule, and the exception status code encoding rule is to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception; the exception information is generated according to a pre-set standard exception information field; the standard exception information field includes at least one of the following: an exception status code, an exception information description, an exception error node and port, an exception error information stack, and an interface uniform resource locator URL where the exception is generated.
2. The method according to claim 1, characterized in that If an exception is detected during the call to the downstream application system, the exception information including the exception status code is determined, including: In the case of successful call to the downstream application system, the exception information including the exception status code in the interface return message fed back by the downstream application system is obtained; and in the case of unsuccessful call to the downstream application system, in the pre-set exception handling module, according to the pre-set exception status code encoding rules and the pre-set standard exception information field, the exception information including the exception status code is generated.
3. The method according to claim 2, characterized in that When called, the exception information is sent to its upstream application system, including: If an exception occurs during an application system call, the exception information including the exception status code will be transparently transmitted to its upstream application system when it is called; If an exception occurs when being called by the front-end page, it is determined whether the preset escape condition is met, and if the preset escape condition is met, the exception information is first escaped, and then the escaped exception information is sent to the front-end page; wherein the escape condition is that the expression accuracy of the exception information meets the preset accuracy requirement.
4. The method according to claim 3, characterized in that: Transmit the exception information including the exception status code to its upstream application system, including: Replace the abnormal error node and port field in the abnormal information with the node IP and port number of the current application system, and connect them in series in front of the abnormal error information stack to obtain the replaced abnormal information; The replaced abnormal information is sent to its upstream application system.
5. The method according to claim 3, characterized in that: Escape exception information, including: The exception status code, exception information description, exception error reporting node and port, and exception error reporting information stack in the exception information are taken out and updated; The updated exception status code, exception information description, exception error reporting node and port, and exception error reporting information stack are concatenated to obtain the escaped exception information.
6. The method according to any one of claims 1 to 5, characterized in that: The abnormal status code encoding rules include: According to the source corresponding to the exception, the first-level status code is set; the source includes at least one of the following: the user end, the current application system, the internal interface of the upstream calling system, and the external third-party interface of the upstream calling system; According to the type of exception, set the second-level status code; the type includes at least one of the following: parameter exception, permission exception, operation exception, business logic exception, null pointer / array out-of-bounds exception, network connection exception, database exception, file IO exception, cache exception, message queue exception, unknown exception; Determine the third-level status code based on the business type corresponding to the exception; Determine the application status code according to the occurrence scenario corresponding to the exception; the occurrence scenario includes at least one of the following: interface module, microservice, front-end page, application system; According to a preset abnormal status code format, the first-level status code, the second-level status code, the third-level status code and the application status code are combined in order to obtain an abnormal status code.
7. An exception handling device, characterized in that: The device comprises: A determination module is used to determine multiple application systems that need to be called to complete the current business operation; A processing module is used for determining, for any of the application systems, exception information including an exception status code if the application system itself generates an exception or detects an exception in the process of calling a downstream application system, and sending the exception information to its upstream application system when called; wherein the exception status code is determined according to a preset exception status code encoding rule, and the exception status code encoding rule is to determine the corresponding status code for the exception according to the source, type, and occurrence scenario corresponding to the exception; the exception information is generated according to a preset standard exception information field; the standard exception information field includes at least one of the following: an exception status code, an exception information description, an exception error node and port, an exception error information stack, and an interface uniform resource locator URL that generates the exception.
8. An exception handling device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the method according to any one of claims 1 to 6 when executed by the processor.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the method described in any one of claims 1 to 6 are implemented.
10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.