HK1109664B - Component error information processing method - Google Patents

Description

Method for processing error information by software component

Technical Field

The invention relates to a method for processing error information by a software component, in particular to a method for processing error information by a software component, which can avoid error number conflict generated in the process of calling a user component by a client program.

Background

In the software component technology, the method for processing various error messages by a component is different from the method for processing the error by software application, and firstly, it should be realized that any error, if not properly processed in the component, will affect the client program calling the method, so the information received by the client program should be clear, and since the client program does not know the logical operation process of the component, the displayed error message must reflect the failed transaction environment, and then the error message is processed and interpreted by the client program accordingly. In the current COM component technology, for example, in the COM component technology, besides AddRef and Release of the IUnknown interface, other methods all have a HRESULT type return value for indicating the result of method invocation, and when the invocation fails, an error number may be returned to make the client program clear the cause of the error, so that corresponding processing may be performed. As shown in FIG. 1, the HRESULT value is a 32-bit integer value that includes three fields, a importance code, a device code, and a return code, where the most significant importance code indicates whether the call was successful. This design allows the method to return multiple success codes as well as failure codes. The lower 16 bits of HRESULT contain the return code for the method call. The middle 15 bits contain more detailed information of this type and the origin of the return value. For the intermediate 15-bit device code, there is a fixed definition in the existing COM specification.

Wherein the devices are defined by COM component technology return codes except when the device code is FACILITY _ ITF. All device codes are generic and they are the same for anyone, anywhere. While FACILITY _ ITF is an exception: it identifies the return code that is specifically associated with the interface that returned this code.

When named, the codes representing successful returns typically have an S _ prefix before their names, while the codes representing failed returns have an E _ prefix before their names. For example: s _ OK, E _ NOINTERFACE, etc.

For the component developer, if the error message return code defined by the COM component cannot meet the requirement, a return value is customized for the method of a certain interface. According to the COM component specification specified by microsoft, first, when a component developer customizes an error number, the device code must be FACILITY _ ITF, which indicates that the error number is associated with an interface, and then an error code is defined. Second, the name of the component or interface should be preceded by the name of the custom return code, such as when the component name is FOO, its error number may be named FOO _ E _ NOINTERFACE, etc.

Custom error numbers provide convenience to the component developer, but while the meaning of a return value tagged with FACILITY _ ITF is related to the interface on which it is returned, the return value itself is not necessarily unique, since by definition of HRESULT, it is only 2¹⁶There are possible returns, but there are thousands of developers developing COM components that define their own error numbers. These error numbers are all labeled FACILITY _ ITF. It is therefore not only possible, but almost certainly possible, for different component interfaces to give different meanings to the same value.

For a client that calls an interface, although the possibility of a collision of error numbers does not necessarily become a problem. For example, when a client knows the interface it calls, it also knows all the success codes that this interface may return; the client will also know most error codes; and there will be a default error handling for those error codes that the client cannot recognize. However, problems may arise when the caller of an interface is itself a member and attempts to propagate the resulting success or error number to other clients. This is because the caller's client cannot understand the meaning of this return value, since the return value was originally returned by a client that is not known to the existing client.

Moreover, for developer-defined error numbers, there are some general rules in the COM component specification as follows:

first, values in the range of 0x0000 and 0x01ff are not to be used as return codes. These values are reserved for the FACILITY _ ITF code defined by COM. Only by following this rule will the user's own defined error number not be confused with the COM defined code.

Second, no FACILITY _ ITF error number is propagated.

Again, as much common COM success and error codes as possible are used.

Also, defining an own HRESULT should be avoided, but may be replaced by using an output parameter in the function.

Disclosure of Invention

The technical problem to be solved by the invention is to provide a method for processing error information by a software component, which can avoid the problems of error number repetition, conflict, error cross-component transmission and the like caused by self-defined error numbers and can clearly express various error information.

In order to solve the technical problems, the invention is realized by the following technical scheme:

when the component method is called, if the pre-defined universal error number in the component platform can meet the actual requirement, returning a universal error number; otherwise, returning a special error number and transmitting error information of character strings or URL types through a cross-process or cross-machine calling process;

the error information is transmitted as follows: judging the calling result of the component method, if the result does not belong to one of the special error numbers, namely the calling result is a successful return value or the universal error number, the stub of the server side collects the calling result and packs the calling result; otherwise, taking out error information from the user stack top of the server, adding the error information behind the calling result, and then packaging the error information; then, the system transmits the packed result to an agent of the client, and after the agent takes the result, if the result is judged not to belong to one of the special error numbers, the unpacking operation is executed, and the calling result is analyzed from the buffer; otherwise, error information is added to the top of the user stack of the client while the unpacking operation is performed.

The invention has the advantages that the problems of repetition, conflict, error cross-component transmission and the like of error numbers caused by the limitation of the number of the user-defined error numbers in the current software component are solved; but also makes the client program more definite about the meaning of each error return.

Drawings

The invention will be described in further detail with reference to the following detailed description and accompanying drawings:

FIG. 1 is a schematic diagram of the bit distribution of HRESULT type return values in COM software components;

fig. 2 is a flow chart of the error information processing procedure according to the present invention.

Detailed Description

The error processing mechanism in the CAR software component technology re-specifies the error processing method on the basis of the COM component technology. Firstly, in most method calls in the CAR component, the type of the return value is defined as ECODE, wherein ECODE is a 32-bit integer, and when the 1 st bit of ECODE is 0, the result value is returned, and the success of the method calling process is indicated; and 1 indicates that a universal error number is returned, and indicates some error generated in the method calling process, such as insufficient memory, network failure and the like. In the CAR component specification, these general error numbers are defined with a definite meaning, and they are the same for anyone, wherever possible. Also, the CAR component prohibits the behavior of the user component to return custom error values to the client. In general, universal error numbers of this ECODE type defined in CAR construction technology will suffice. Since the 32-bit error number can be used as a return value of the interface method and directly returned to the user, the error numbers which are already defined are returned particularly to all components provided by the system and components called back by the system. Because the error numbers have definite meanings and wide application range, no additional information needs to be provided.

Since the general error number of the ECODE type cannot meet the actual requirements of some clients for the invocation of the user component in some special cases, three special error numbers are defined as follows: e _ ERROR _ STRING, E _ ERROR _ STRING _ A, and E _ ERROR _ URL, which are also 32-bit ERROR numbers, respectively, identify that a component method call will return a wide STRING, narrow STRING, and URL type ERROR information. Since the component method cannot directly return a character string or URL, the CAR component platform realizes the transfer of the error information from the user component of the server to the client program by means of remote calling. Wherein, E _ ERROR _ STRING is an ERROR number of a wide STRING type and is used for indicating that ERROR information of no more than 254 wide STRINGs is to be returned; e _ ERROR _ STRING _ A is an ERROR number of an ASCII STRING type and is used for indicating that ERROR information of not more than 509 ASCII STRINGs is to be returned; the E _ ERROR _ URL is an ERROR number of a URL type, and since the URL is in the form of an ASCII string, it is used to indicate that an ASCII string of not more than 509 bytes will be "returned". At this point, since the user component provides the error message and its processing type, the CAR component platform processes the message and the client can determine the type of error message from the return of the call and obtain the description in an appropriate manner. For this purpose, the system may be configured to provide a set of calls for setting and reading the error description information, i.e. to complete the access of the error description information, which may be implemented by defining the manner of calling the function, etc. With such specification, various problems caused by the developer customizing the wrong return value are largely avoided.

As mentioned above, the components provided by the system and the components called back to the user by the system have the defined return values, so that the error number can be directly returned to the client program without using the aforementioned call, namely, without passing error information. And the error information of character strings and URL types cannot be directly returned to the user, so that the transmission of the error information is realized by means of a cross-process or cross-machine calling process.

In order to implement the above-described calling, a storage method of the error information should be set first, which is a precondition that the error information can be transferred to the client program in the calling process of the cross-process and the cross-machine. In the method of the invention, the error information can be stored on the top of the user stack of the service thread or the client thread in the transmission process. The storage format of each error message at the top of the user stack is as follows: the code comprises 512 bytes in total, wherein the first two bytes are used for describing the length of a wide character string, an ASCII code character string or a URL; followed by a specific broad string, ASCII string or URL; then is the string end flag '\ 0', which takes two bytes for wide strings and one for ASCII strings or URLs. And respectively designing two APIs for the three special error messages, wherein one API is used for storing the error messages to the top of the user stack, and the other API is used for taking out the error messages from the top of the user stack. The operation of accessing the top of the user stack can be realized by system call, and certainly, if the user stack is designed to be aligned to 1M or more than 1M, the user stack can be directly read and written in a user state, so that multiple times of system call is avoided, and the system efficiency is improved.

Then, the transfer of the error information can be realized through cross-process or cross-machine calling processes. As shown in fig. 2, in one embodiment, the calling steps are as follows: the cross-process or cross-machine call process begins when a client of a client initiates a call to a user component of a server at step 200. In step 201, a Proxy (Proxy) is created in the client process, and the Proxy of the client collects parameters required by the call and packages the parameters, wherein the packaging refers to compressing the collected parameters into a buffer; then step 202, the system initiates a service thread at the server, and transmits the packed data to the stub; in step 203, the Stub (Stub) unpacks the parameters, i.e. parses the parameters from the buffer, sets the stack structure, and then performs the component method call; after the component method is called, if the calling result belongs to one of the special error numbers, the error information is pressed to the top of the user stack of the server. Since the error message is transmitted from the client to the client in the client user component, the proxy of the client and the stub of the server do not perform any special operations for packing and unpacking the call parameters in the execution of steps 201 and 203. Subsequently, the transmission of the error information can be performed. In step 204, the result of the above call is judged, if the result belongs to one of the special error numbers, step 206 is executed, and the stub takes out the error information from the user stack top of the server; then, step 207 is entered, the error message taken from the top of the user stack at the server is added behind the call result, i.e. the special error number, and they are packed together, i.e. the call result and the error message are compressed together in a buffer; if the calling result does not belong to one of the special error numbers, namely the calling result is a successful return value or a universal error number, entering step 205, collecting the calling result and packaging the calling result; after packaging, the method enters step 208, the system transmits the packaged result to the agent, and after the agent takes the result, the agent judges whether the result belongs to one of the special error numbers or not in step 209; if the error number belongs to one of the special error numbers, the method enters step 211, unpack operation is executed, namely error information is analyzed from the buffer, meanwhile, the error information is added to the user stack top of the client, and then the whole calling process is finished after the step 212 is executed; otherwise, step 210 is entered, the unpacking operation is directly performed, i.e. the calling result is parsed from the buffer, and then step 212 is entered to complete the transmission of the error information.

Claims (3)

1. A method for a software component to process error information, comprising the steps of:

when the component method is called, if the pre-defined universal error number in the component platform can meet the actual requirement, returning a universal error number; otherwise, returning a special error number and transmitting error information of character strings or URL types through a cross-process or cross-machine calling process;

the error information is transmitted as follows: judging the calling result of the component method, if the result does not belong to one of the special error numbers, namely the calling result is a successful return value or a general error number, the stub of the server end collects the calling result and packs the calling result; otherwise, taking out error information from the user stack top of the server, adding the error information behind the calling result, and then packaging the error information; then, the system transmits the packed result to an agent of the client, and after the agent takes the result, if the result is judged not to belong to one of the special error numbers, the unpacking operation is executed, and the calling result is analyzed from the buffer; otherwise, error information is added to the top of the user stack of the client while the unpacking operation is performed.

2. The method of claim 1, wherein the universal error number is a 32-bit integer having a first bit of 1, and each universal error number corresponds to a unique error message in the component platform.

3. The method of processing error information by a software component of claim 1, wherein the special error number comprises: an error number indicating error information of a wide string type, an error number indicating error information of an ASCII string type, and an error number indicating error information of a URL type.