Transaction response state processing method and system based on RPC exception return

Abstract

The invention relates to a transaction response state processing method based on RPC (Remote Procedure Call) exception return, which comprises the following steps that: a service party defines a specific transaction response code, and packages the transaction response code into an exception class object to be thrown out according to a transaction response state corresponding to an exception class when a transaction error occurs; ensuring that the transaction response code is consistent with the transaction response state corresponding to the abnormal class; the consumer judges a transaction response state according to the abnormal class object after receiving the abnormal class object thrown by the service party; when the consumer cannot process the abnormal class object, the abnormal class object is thrown to an upstream system, and it is ensured that the abnormal class object is kept consistent with the transaction response state of the response code in the transmission process; and the upstream consumer repeats the second step until a certain system receives the abnormal class object, and judges the transaction response state according to the abnormal class object to carry out correct error processing. According to the method, information loss and transaction processing risks caused by multiple times of transmission of the transaction code in a traditional method are avoided, the cost of global management of the response code is reduced, and the limitation on transaction response processing of the system is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a transaction response status processing method and system based on RPC abnormal return. Background Art

[0002] In traditional distributed systems, the negotiation and formulation of transaction interfaces are usually carried out between the direct caller and the service provider. This direct communication helps both parties reach a consensus on interface specifications, data formats, and transaction processes. However, this approach has limitations because it relies on the coordination and agreement of both parties, and each interface change requires renegotiation, which may increase communication costs and cause delays in transaction processing.

[0003] When errors are generated by the service provider, the consumer may not be able to handle these errors or may not be interested in the specific content of the errors. In this case, the consumer usually passes the error information to the upstream system. This chain error transmission mechanism helps to ensure the traceability of errors, but it also brings the risk of information loss, especially when the error information is not correctly parsed or recorded during the transmission process, the service provider will not be able to correctly interpret the error information. The service provider usually provides a response code returned by this system, which is valuable to the direct caller because it can provide feedback on the status of transaction processing. However, for response codes that are not directly generated by the service provider, due to the lack of a unified standard or format, omissions or incorrect parsing often occur. This results in the consumer being unable to accurately understand the specific transaction response status represented by the transaction response code, thereby affecting the accuracy and reliability of the transaction.

[0004] In order to solve the problems of communication costs and inaccurate information, a unified response code management system can be developed to manage global response codes. This approach can unify the communication standards between different systems and reduce misunderstandings and communication costs. However, the cost of implementing a unified response code management system is huge because it requires all systems to follow the same set of standards to formulate response codes, and it may require large-scale modifications and upgrades to the response codes of existing systems. In addition, a unified response code management system will also limit the system's flexible response to specific situations. Summary of the invention

[0005] In order to address the deficiencies of the prior art, the present invention realizes the use of RPC to allow consumers to call remote methods like local parties, forces each service in the call chain to carry transaction response status information through exception classes, and uses its grammatical characteristics to prompt users to perform unknown status processing, thereby avoiding information loss during account transaction calls and circumventing transaction processing risks.

[0006] To achieve the above objectives, the technical solutions adopted by the present invention include:

[0007] A transaction response status processing method based on RPC abnormal return, characterized by comprising:

[0008] S1. Define exception classes uniformly. Each exception class corresponds to a transaction response status and also carries the corresponding transaction response status information.

[0009] S2. The service provider defines a specific transaction response code, and when a transaction error occurs, the service provider packages the transaction response code into an exception class object and throws it according to the transaction response status corresponding to the exception class;

[0010] S3. After receiving the exception class object thrown by the service party, the consumer determines the transaction response status according to the exception class object;

[0011] S4. When the consumer cannot process the exception object, it throws the exception object to the upstream system to ensure that the exception object remains consistent with the response status of the transaction response code during the transmission process;

[0012] S5. The upstream consumer repeats step S2 until a certain system receives the exception class object, and determines the transaction response status according to the exception class object and performs correct error handling.

[0013] Exemplarily, S2 further includes that the service party adopts a unified exception structure when defining exception class objects, including a basic exception class and a specific exception class, wherein the basic exception class contains a predefined general transaction response status and detailed error information, and the specific exception class inherits from the basic exception class and contains a transaction response status, detailed error information and system custom information.

[0014] Specifically, by adopting a unified exception structure, the service provider can ensure that all exception information follows the same pattern and standard, which helps consumers understand and handle exceptions more easily, and also simplifies system maintenance and development. The basic exception class includes a general transaction response status and detailed error information. The general transaction response status information provides consumers with basic information about whether the transaction is successful, failed, or in an unknown state, which is the basis for preliminary error classification and processing. The detailed error information can include the specific cause of the error, the scope of impact, the recommended operation, etc., which provides consumers with a deeper understanding of the error and more precise error handling capabilities. Specific exception classes are extensions of the basic exception class. They contain custom information in addition to general information and detailed error information, and can carry necessary data information for response processing. These detailed information are combined with basic and specific exception classes, so that the service provider can provide more detailed error classification. This allows consumers to adopt different processing strategies according to the specific type of exception, thereby providing more targeted error responses. The unified exception structure makes it easier to add new exception types or modify existing exception classes. Service providers can expand exception classes as needed to adapt to new error handling requirements without destroying the existing system.

[0015] Exemplarily, S3 further includes that when the consumer determines the transaction response status, the consumer decides whether error handling is required based on actual needs, and if no handling is required, the exception class object is directly passed to the upstream system.

[0016] Specifically, the consumer decides whether error handling is needed based on actual needs. If the consumer needs to handle the exception, the response information can be processed through the response status and response code corresponding to the exception class object. If no processing is required, the exception class object is passed to the upstream system.

[0017] The response code is set by the service in the exception class object to indicate the specific result or error type of the transaction. The response code provides a standardized way for consumers to identify and classify exceptions. After receiving the exception object, the consumer will check whether it contains a predefined response code. These codes help consumers quickly determine the nature of the exception and whether specific error handling measures need to be taken. If the response code contained in the exception object indicates a known error condition, the consumer will use this information to decide whether further error handling is required. For example, if the response code indicates a minor error that can be ignored, the consumer may choose not to perform additional processing. By providing clear error information and response status, the service can improve the end-user experience. Users can get feedback on the status of the transaction more quickly and take action as needed.

[0018] Exemplarily, the S3 further includes:

[0019] S301, if it is determined that no further error processing is required, directly passing the exception class object to the upstream system;

[0020] S302: If it is determined that further error handling is required, the exception class object is captured and processed.

[0021] Specifically, when the consumer receives the exception class object, if it determines that the current exception does not need to be processed by the system at this level, the consumer passes the exception class object to the upstream system. By passing the exception class object to the upstream system, the consumer maintains the integrity of the call chain and ensures that the exception information can flow up along the call chain until a suitable processing point is found. If the consumer already knows the exception type and determines that no action is needed, directly passing the exception can avoid unnecessary error handling at the current level and improve the efficiency of the system. In some cases, the consumer may not have enough information or authority to handle a specific exception, so it is necessary to hand over the decision-making power to the upstream system. During the transmission process, the exception class object maintains its original state, that is, the response status and response code, which helps the upstream system accurately understand the context of the exception.

[0022] The consumer determines the response status based on the exception class object, identifies the error that requires the intervention of the system at this level, and takes appropriate processing measures. After catching the exception, the consumer may try to recover the operation, such as retrying the failed request, providing alternative solutions, or performing compensating transactions. When handling exceptions, the consumer can choose to record detailed error logs to facilitate problem tracking and subsequent analysis.

[0023] Exemplarily, S5 further includes: after capturing the exception class object, the system automatically matches the corresponding error handling strategy according to the transaction response status represented by the exception class object, without the need for manual analysis of the exception content.

[0024] Specifically, after capturing the exception class object, the consumer can automatically identify the exception class in the exception. The system will set a set of error handling strategies, and each strategy corresponds to the set exception class. This predefined mechanism enables the system to respond quickly to different exception class objects. According to the transaction response status represented by the exception class object, the corresponding error handling strategy can be automatically matched without parsing the internal information of the exception class object, including the response code and other information. The response code is decoupled from the response status. As the system iterates, new processing strategies can be added for new exception types without modifying the existing automated processing logic.

[0025] In addition, the automation mechanism allows logical judgment to be added when matching error handling strategies, such as selecting different handling strategies based on the severity, frequency of occurrence, or contextual information of the exception. Automation can also reduce the amount of code that developers need to write and maintain. This mechanism eliminates the need for maintainers to write specific handling code for each exception class. Efficient automated error handling can reduce system downtime and improve the end-user experience.

[0026] Exemplarily, S5 also includes: during the transmission process of the exception class object, ensuring that the exception class object can carry complete transaction response status information and will not destroy the definition principle of the system's own response code, while prompting the user to process important exception class objects at the grammatical level.

[0027] Specifically, the information carried by the exception class object during the transmission process is not limited to the error code, but also includes sufficient context information to ensure that the recipient can fully understand the specific situation and impact of the exception. Each level of the system has its own response code definition principles, and the design of the exception class object should respect and be compatible with these principles to ensure interoperability and consistency between different systems. As a means of encapsulation, the exception class object encapsulates error information and related states together to ensure that the information is not lost or tampered with when transmitted across systems or services. The complete information carried by the exception class object helps to track the source and propagation path of the error in a complex system architecture.

[0028] Exemplarily, S5 further includes automatically recording an error log according to the response code information of the abnormal object, and triggering a corresponding compensation or retry mechanism according to the abnormal object.

[0029] Specifically, although error handling is automated, the system usually records all exceptions and corresponding processing actions for subsequent monitoring and analysis. For certain types of errors, the system automatically triggers compensation operations to correct or undo the executed operations. For recoverable errors, the system implements a retry mechanism to automatically retry failed operations to increase the possibility of the operation's eventual success.

[0030] The second aspect of the present invention further provides a transaction response status processing system based on RPC abnormal return, which is used to execute any method described in claims 1-7, including:

[0031] The exception object class definition module is used to uniformly define exception class objects. Each exception class object corresponds to a transaction response status and also carries the corresponding transaction response status information.

[0032] The service provider defines a response code module, which is used by the service provider to define a specific transaction response code. When a transaction error occurs, the service provider packages the transaction response code into an exception class object and throws it out according to the transaction response status corresponding to the exception class object.

[0033] The consumer receiving judgment module is used for the consumer to judge the transaction response status according to the exception class of the exception class object after receiving the exception class object thrown by the service party;

[0034] The exception information transmission module is used to throw the exception object to the upstream system when the consumer cannot process the exception object, ensuring that the response code and response status of the exception object are consistent during the transmission process;

[0035] The error handling module is used to perform correct error handling according to the transaction response status of the exception class object after a system receives the exception class object.

[0036] A second aspect of the present invention further provides an electronic device, characterized in that it includes a processor and a memory;

[0037] The memory is used to store computer programs;

[0038] The processor is used to execute the method according to any one of claims 1 to 7 by calling a stored computer program.

[0039] The third aspect of the present invention also provides a computer program product, comprising a computer program and / or instructions, characterized in that when the computer program and / or instructions are executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

[0040] A fourth aspect of the present invention also relates to a computer program product, comprising a computer program and / or instructions, characterized in that the computer program and / or instructions implement the steps of the above method when executed by a processor.

[0041] The beneficial effects of the present invention are as follows: the RPC response status processing method based on exception types proposed by the present invention introduces different types of exception classes to force each service in the call chain to carry transaction response status information, and uses the syntax characteristics of RPC to prompt the user to perform unknown status processing. This method avoids information loss and transaction processing risks in traditional practices, while reducing the high cost of implementing a global response code system and the restrictions on system flexibility. Through the exception mechanism, transaction status information can be more effectively transmitted and processed in a distributed system, improving the robustness and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 The figure is a flow chart of a method for processing a transaction response status based on an RPC exception return according to the present invention.

[0043] Figure 2 The figure is a schematic diagram of the structure of the transaction response status processing system based on RPC exception return of the present invention.

[0044] Figure 3 The figure is a schematic diagram of the execution logic of the transaction response status processing method based on RPC exception return of the present invention. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments in 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.

[0046] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. At the same time, in the description of the present invention, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0047] Service provider definition: A service provider is a system or component that provides a specific service or function. In the context of remote procedure call (RPC), a service provider is the party that receives a request and performs the corresponding operation. The service provider is responsible for executing the business logic, processing the request, and returning the result or throwing an exception when an error occurs. The service provider is also responsible for defining and maintaining response codes, which are used to indicate the processing status of the request.

[0048] Definition of consumer: A consumer is a system or component that initiates an RPC call and requires services or functions provided by a server. The consumer is responsible for sending requests to the server and processing responses or exceptions returned by the server. If a consumer receives an exception, it needs to decide whether to handle the error or pass the exception to the upstream system based on the error information carried by the exception class.

[0049] Upstream consumer definition: Upstream consumer refers to the system or component that is upstream of the current consumer in the call chain, that is, the caller of the current consumer. The upstream consumer further processes the exception or passes the exception upstream again. It is responsible for ensuring that the exception information can be correctly passed in the call chain and finally handled correctly.

[0050] Upstream system definition: The upstream system refers to any system or component that is upstream of the current system in the call chain, including upstream consumers. The upstream system is responsible for receiving exceptions passed from the downstream and performing corresponding error handling based on the exception information.

[0051] The service provider provides services, and the consumer requests services. The upstream consumer is the caller of the consumer, and the upstream system is all the systems or components located upstream in the entire call chain. They work together to ensure the correct handling of requests and effective management of exceptions.

[0052] If there is an online payment system including a service provider (payment service provider) and multiple consumers (websites or applications using payment services), the technical solution of the present invention is used to process abnormal objects.

[0053] The first aspect of the present invention relates to a method for processing a transaction response status based on an RPC exception return, as follows: Figure 1 and Figure 3 As shown, including:

[0054] S1. Define exception classes uniformly, and each exception class corresponds to a transaction response status:

[0055] FailureException: Transaction response status failed

[0056] UnknowException: Transaction response status unknown

[0057] S2. The service provider defines a specific transaction response code, and when a transaction error occurs, the service provider packages the transaction response code into an exception class object and throws it out according to the response status corresponding to the exception class, ensuring that the exception class object is consistent with the response status corresponding to the transaction response code;

[0058] The Payment service defines the following response codes:

[0059] 1: Transaction failed (e.g. insufficient balance)

[0060] 2: The transaction is unknown (such as network timeout);

[0061] S3. After receiving the exception class object thrown by the service party, the consumer determines the transaction response status according to the exception class object;

[0062] Website A (consumer) initiates a payment request to the payment service.

[0063] The payment service processes the request and triggers an exception due to insufficient balance. The response code 1 is packaged into a FailureException exception object, indicating that the transaction response status has failed, and is thrown.

[0064] S301, if it is determined that no further error processing is required, directly passing the exception object to the upstream system;

[0065] Website A receives the FailureException and recognizes that the transaction response status is a failure. According to the preset strategy, it is considered that no further processing is required and the user can be directly prompted with the reason for the failure (for example, prompting the user that the balance is insufficient).

[0066] Website A continues to pass the exception class object to the upstream system (such as the payment gateway).

[0067] S302: If it is determined that further error handling is required, the exception class object is captured and processed.

[0068] If the exception received by website A is UnknowException, it is recognized that the transaction response status is unknown, which affects the consistency of system data. Therefore, it is decided that further processing is required. At the same time, the response code 2 of the exception object is parsed and the compensation mechanism is run according to the automatic strategy (for example, try to reconnect to the payment service).

[0069] Website A catches the exception and tries to perform alternative actions, such as querying the transaction status or prompting the user to check the network connection.

[0070] S4. When the consumer cannot process the exception object, it throws the exception object to the upstream system to ensure that the response code and response status of the exception object are consistent during the transmission process;

[0071] If website A fails in its attempt and cannot determine the transaction status, it will throw the exception class object to the upstream system again. During this process, the exception class object maintains its response code and response status to ensure the consistency of information.

[0072] S5. The upstream consumer repeats step S3 until a certain system receives the exception class object and performs correct error processing based on the exception class object.

[0073] The payment gateway (upstream consumer) receives the exception class object and identifies the transaction response status.

[0074] Based on its internal logic and the response code, the payment gateway decides what action to take, such as logging an error, notifying an administrator, or triggering a compensating transaction.

[0075] Another aspect of the present invention also relates to a transaction response status processing system based on RPC abnormal return, the structure of which is as follows: Figure 2 As shown, including:

[0076] The service provider defines a response code module, which is used by the service provider to define a specific response code according to the transaction result, and when an error occurs, the response code is packaged into an exception class object and thrown;

[0077] The consumer receiving judgment module is used for the consumer to judge the transaction response status according to the exception class object after receiving the exception class object thrown by the service party;

[0078] The exception information transmission module is used to throw the exception object to the upstream system when the consumer cannot process the exception object, ensuring that the response code and response status of the exception object are consistent during the transmission process;

[0079] The error handling module is used to perform correct error handling according to the exception class object after a system receives the exception class object.

[0080] By using this system, the above-mentioned operation processing method can be executed and the corresponding technical effects can be achieved.

[0081] An embodiment of the present invention also provides an electronic device for executing the above method. As an implementation device of the method, the electronic device at least has a processor and a memory, and in particular, the memory stores data and related computer programs required for executing the method, such as storing related programs for a transaction response status processing method based on an RPC exception return, etc., and the processor calls the data and programs in the memory to execute all the steps of the implementation method and obtains the corresponding technical effect.

[0082] Preferably, the electronic device may include a bus architecture, the bus may include any number of interconnected buses and bridges, and the bus will include various circuits linked together by one or more processors and memories. The bus may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are all well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the receiver and transmitter. The receiver and transmitter may be the same component, i.e., a transceiver, providing a unit for communicating with various other systems over a transmission medium. The processor is responsible for managing the bus and general processing, while the memory may be used to store data used by the processor when performing operations.

[0083] In addition, the electronic device may further include components such as a communication module, an input unit, an audio processor, a display, and a power supply. The processor (or controller, operation control) used may include a microprocessor or other processor device and / or a logic device, which receives input and controls the operation of various components of the electronic device; the memory may be one or more of a cache, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory, or other suitable devices, which may store the above-mentioned related data information, and may also store a program for executing related information, and the processor may execute the program stored in the memory to realize information storage or processing, etc.; the input unit is used to provide input to the processor, for example, it may be a key or a touch input device; the power supply is used to provide power to the electronic device; the display is used to display display objects such as images and text, for example, it may be an LCD display. The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor to provide input signals and receive output signals, which may be the same as the case of a conventional mobile communication terminal. Based on different communication technologies, multiple communication modules may be provided in the same electronic device, such as a cellular network module, a Bluetooth module and / or a wireless local area network module, etc. The communication module (transmitter / receiver) is also coupled to a speaker and a microphone via an audio processor to provide an audio output via the speaker and receive an audio input from the microphone, thereby realizing a common telecommunication function. The audio processor may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor is also coupled to a central processor, so that recording can be performed on the machine through the microphone, and the sound stored on the machine can be played through the speaker.

[0084] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, electronic devices or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention 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.

[0085] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of 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 produce 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 system that specifies the functions of a box or multiple boxes.

[0086] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction system, which is implemented in the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0087] 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 in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps of the functions specified in a box or multiple boxes. Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they know the basic creative concept. Therefore, the attached claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0088] The above is only a preferred specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A transaction response status processing method based on RPC abnormal return, characterized in that: include: S1. Define exception classes uniformly. Each exception class corresponds to a transaction response status and also carries the corresponding transaction response status information. S2. The service provider defines a specific transaction response code, and when a transaction error occurs, the service provider packages the transaction response code into an exception class object and throws it according to the transaction response status corresponding to the exception class; S3. After receiving the exception class object thrown by the service party, the consumer determines the transaction response status according to the exception class object; S4. When the consumer cannot process the exception object, it throws the exception object to the upstream system to ensure that the exception object remains consistent with the response status of the transaction response code during the transmission process; S5. The upstream consumer repeats step S2 until a certain system receives the exception class object, and determines the transaction response status according to the exception class object and performs correct error handling.

2. The method according to claim 1, characterized in that The S2 further includes that the service party adopts a unified exception structure when defining exception class objects, including a basic exception class and a specific exception class, wherein the basic exception class includes a pre-defined general transaction response status and detailed error information, and the specific exception class inherits from the basic exception class and includes a transaction response status, detailed error information and system custom information.

3. The method according to claim 1, characterized in that The S3 further includes that when the consumer determines the transaction response status, the consumer decides whether error handling is required based on actual needs. If no handling is required, the exception class object is directly passed to the upstream system.

4. The method according to claim 1, characterized in that: The S3 also includes: S301, if it is determined that further error processing is not required, directly passing the exception class object to the upstream system; S302, if it is determined that further error processing is required, capturing and processing the exception class object.

5. The method according to claim 1, characterized in that The S5 further includes: after capturing the abnormal object, the system automatically matches the corresponding error handling strategy according to the transaction response status represented by the abnormal object, without manually parsing the content of the abnormal object to determine the transaction response status and then process it.

6. The method according to claim 1, characterized in that The S5 also includes: during the transmission process of the exception class object, ensuring that the exception class object can carry complete transaction response status information and will not destroy the definition principle of the system's own response code. At the same time, for important transaction response status, the syntax level of the detected exception is checked and the user is prompted to handle the unknown important transaction response status.

7. The method according to claim 1, characterized in that The S5 further includes automatically recording an error log according to the transaction response code information of the abnormal object, matching a corresponding error handling strategy according to the transaction response state represented by the abnormal class object, and automatically triggering a corresponding compensation or retry mechanism.

8. A transaction response status processing system based on RPC abnormal return, used to execute any method described in claims 1-7, characterized in that: include: The exception class definition module is used to uniformly define exception classes. Each exception class corresponds to a transaction response status and also carries the corresponding transaction response status information. The service provider defines a response code module, which is used by the service provider to define a specific transaction response code. When a transaction error occurs, the service provider packages the transaction response code into an exception class object and throws it out according to the transaction response status corresponding to the exception class object. The consumer receiving judgment module is used for the consumer to judge the transaction response status according to the exception class of the exception class object after receiving the exception class object thrown by the service party; The exception information transmission module is used to throw the exception object to the upstream system when the consumer cannot process the exception object, ensuring that the response code and response status of the exception object are consistent during the transmission process; The error handling module is used to perform correct error handling according to the transaction response status of the exception class object after a system receives the exception class object.

9. An electronic device, characterized in that: including a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the method according to any one of claims 1 to 7 by calling a stored computer program.

10. A computer program product comprising a computer program and / or instructions, characterized in that: When the computer program and / or the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images