专利名称：软件构件处理错误信息的方法
技术领域：
本发明涉及一种软件构件处理错误信息的方法，尤其涉及一种可避免客户程序调用用户构件过程中，产生错误号冲突的软件构件处理错误信息的方法。
背景技术：
在软件构件技术中，构件对各种错误信息的处理方法与软件应用在错误处理上的方法不尽相同，首先应该意识到任何错误如果在构件里得不到妥善处理，都将影响调用该方法的客户端程序，因此客户端程序接受到的信息应该是明白无误的，又由于客户端程序并不知道构件的逻辑运行过程，所以显示错误信息必须反映失败的事务环境，再由客户端程序依此进行处理和解释。在目前的COM构件技术中，例如在COM构件技术中，除了IUnknown接口的AddRef和Release，其他方法都有一个HRESULT类型的返回值，用于表示方法调用的结果，当调用失败时，可返回一个错误号以使客户端程序明确其出错的原因，从而可进行相应的处理。如图1所示，该HRESULT值是一个32位的整型值，它包括了重要程度代码、设备代码和返回代码三个域，其中，最高位的重要程度代码表示调用是否成功。这种设计使得方法可以返回多个成功代码以及失败代码。HRESULT的低16位包含的就是方法调用的返回代码。中间的15位包含的是此类型及返回值起源的更详细的信息。对于中间的15位设备代码，在现有的COM技术规范中都有其固定的定义。
其中，除了当设备码为FACILITY_ITF之外，其余设备都由COM构件技术定义的返回代码。所有的设备码都是通用的，它们对任何人、在任何地方都是相同的。而FACILITY_ITF却是一个例外它标识的是与返回此代码的接口特定相关的返回代码。
命名时，表示成功返回的代码在其名称前通常都有一个S_前缀，而表示失败返回的代码在其名称前的前缀则是E_。例如S_OK、E_NOINTERFACE等。
对于构件开发者来说，如果COM构件定义的错误信息返回代码不能满足需要，那就得为某个接口的方法自定义一个返回值。根据微软规定的COM构件技术规范，首先，构件开发者自定义错误号时，设备代码必须是FACILITY_ITF，表示这个错误号与某接口关联在一起，然后定义一个错误码。其次，在自定义的返回代码的命名上，应该在名称前面加上构件或接口的名称，如当构件名称为FOO时，其错误号可命名为FOO_E_NOINTERFACE等。
自定义错误号，为构件开发者提供了方便，但是，虽然用FACILITY_ITF标记的返回值的含义与返回它的接口相关，但返回值本身却并不一定是唯一的，因为根据HRESULT的定义，只有216个可能的返回值，但是却有成千上万的开发人员在开发定义有他们自己错误号的COM构件。所以这些错误号均被标记为FACILITY_ITF。因此不同的构件接口将不同的含义赋予同一值不仅是可能的，而且几乎可以肯定会出现这种情况。
对于调用某个接口的客户程序，虽然错误号出现冲突的可能性并不一定会成为一个问题。例如，当客户程序知道它所调用的接口时，它也就知道此接口可能会返回的所有成功代码；客户程序也将知道大多数错误代码；并且对于那些客户程序不能识别的错误代码，都将有一个默认的错误处理。但是，当某个接口的调用者本身也是一个构件，并试图将所得到的成功或错误号传播给其他客户程序时，就可能会出现问题了。这是由于该调用者的客户程序无法理解这个返回值的意思，因为该返回值最初是由现有客户程序并不知道的那个客户返回的。
而且，对于开发人员自定义的错误号，COM构件技术规范中还有如下一些一般性的规则首先，不要将0x0000及0x01ff范围内的值作为返回代码。这些值是为COM所定义的FACILITY_ITF代码而保留的。只有遵循这一规则，才不致使用户自己定义的错误号与COM所定义的代码相混淆。
其次，不要传播FACILITY_ITF错误号。
再次，尽可能地使用通用的COM成功及错误代码。
还有，应避免定义自己的HRESULT，而是可以通过在函数中使用一个输出参数来代替。
发明内容
本发明要解决的技术问题是提供一种软件构件处理错误信息的方法，该方法可避免产生由于自定义错误号引起的错误号重复、冲突和错误地跨构件传递等问题，并且可明确地表达各种错误信息。
为解决上述技术问题，本发明是通过以下技术方案实现的构件方法调用时，若构件平台中预先定义的通用错误号能满足实际需要，则返回一个通用错误号；否则，返回一个特殊错误号，然后通过跨进程或跨机器调用过程，传递字符串或URL类型的错误信息；所述错误信息的传递过程如下判断方法调用的结果，如果该结果不属于特殊错误号中的一个，即调用结果为成功返回值或为所述通用错误号时，则服务端的存根将收集调用结果并将该调用结果打包；否则，从服务端的用户栈顶取出错误信息，将所述错误信息添加在该调用结果的后面，然后将其打包；随后，系统将打包后的结果传递给客户端的代理，代理拿到结果后，如果经判断该结果不属于特殊错误号中的一个，则执行解包操作，从缓冲区中将调用结果解析出来；否则，在执行解包操作的同时将错误信息添加到客户端的用户栈顶。
本发明由于采用了上述技术方案，具有这样的有益效果，即解决了目前软件构件中，由于自定义错误号数量上的限制，而产生错误号间的重复、冲突及错误地跨构件传递等问题；而且可使客户端程序更明确各个错误返回的含义。
下面结合附图与具体实施方式
对本发明作进一步详细的说明图1是COM软件构件中HRESULT类型返回值的位分布原理图；图2是本发明所述错误信息处理过程流程图。
具体实施例方式
CAR软件构件技术中的错误处理机制，在COM构件技术的基础上，重新规范了错误处理方法。首先，在CAR构件中的大多数方法调用中，都将返回值的类型定义为ECODE，其中ECODE是一个32位整型，当其第1位为0时表示返回的是成功值，表示方法调用过程成功；而为1时表示返回的是通用错误号，表示方法调用过程中产生的某种错误，如内存不足、网络故障等。在CAR构件技术规范中，定义的这些通用错误号有明确的意义，它们对任何人、在任何场合，都是相同的。而且，CAR构件禁止了用户构件向客户程序返回自定义错误值的行为。在一般情况下，CAR构件技术中所定义的这种ECODE类型的通用错误号都可以满足需要。由于这种32位的错误号可以作为接口方法的返回值，直接返回给用户，因此尤其是对于系统提供的所有构件、以及系统回调的构件，都会返回这些已经定义的错误号。由于，这些错误号意义明确，适用范围广，因此不需要提供额外的信息。
由于在某些特殊情况下，ECODE类型的通用错误号无法满足某些客户程序对用户构件调用的实际需要，因此定义如下三个特殊的错误号E_ERROR_STRING、E_ERROR_STRING_A和E_ERROR_URL，它们也是32位的错误号，分别标识构件方法调用将返回一个宽字符串、窄字符串和URL类型的错误信息。由于构件方法不可能直接返回一个字符串或URL，所以CAR构件平台通过远程调用的方式来实现这些错误信息由服务端的用户构件到客户程序间的传递。其中，E_ERROR_STRING为宽字符串类型的错误号，用于标示将“返回”一个不超过254个宽字符串的错误信息；E_ERROR_STRING_A为ASCII字符串类型的错误号，用于标示将“返回”一个不超过509个ASCII字符串的错误信息；E_ERROR_URL为URL类型的错误号，由于URL是以ASCII字符串的形式出现的，因此用于标示将“返回”一个不超过509个字节的ASCII字符串。这时，由于用户构件提供了错误信息以及它的处理类型，CAR构件平台会处理这些信息，客户程序可以从调用的返回值判断出错误信息的类型，并用合适的方式得到这些描述信息。为此，系统可设置提供一组调用，以用于错误描述信息的设置与读取，即完成错误描述信息的存取，这可通过定义调用函数的方式等实现。通过这样规范之后，极大地避免了因为开人发员自定义错误返回值而引起的各种问题。
如前所述，对于系统提供的构件、以及系统向用户回调的构件，由于其返回值都是已经定义的，所以并不需要使用前面提到调用，即不需要进行错误信息的传递，而可直接将错误号返回给客户程序。而字符串和URL类型的错误信息无法直接返回给用户，因此需借助跨进程或跨机器调用的过程来实现错误信息的传递。
为了实现上述调用，首先应设定错误信息的存储方式，这是实现在跨进程以及跨机器的调用过程中，向客户程序传递错误信息能够实现的前提。在本发明所述的方法中，将错误信息在传递过程中可存放在服务线程或客户线程的用户栈顶。每个错误信息在用户栈顶的存放格式如下共包括512个字节，其中，前两个字节用于描述宽字符串、ASCII码字符串或URL的长度；随后是具体的宽字符串、ASCII字符串或者URL；然后是字符串结束标志‘\0’，对于宽字符串而言该标志占两个字节，而对于ASCII字符串或URL而言该标志占一个字节。分别对上述三种特殊错误信息各设计两个API，一个将错误信息存放到用户栈顶，另一个则是从用户栈顶取出错误信息。访问用户栈顶的操作可以通过系统调用实现，当然如果用户栈是被设计成1M或1M以上对齐的话，则直接可以在用户态下读写，从而避免了多次系统调用，提高系统效率。
随后，就可通过跨进程或跨机器的调用过程，实现对错误信息的传递。如图2所示，在一个实施例中，其调用步骤如下在步骤200客户端的客户程序发起对服务端的用户构件的调用，则跨进程或跨机器调用过程开始。在步骤201，在客户进程创建一个代理(Proxy)，客户端的代理将收集调用所需的参数并将所述参数打包，所谓打包是指将收集到的参数压缩成一个缓冲区；随后到步骤202，系统在服务端发起一个服务线程，将到打包后的数据传递给存根；在步骤203，存根(Stub)将参数解包即从缓冲区中将参数解析出来、设置堆栈结构，然后进行方法调用；方法调用结束后，如果该调用结果属于特殊错误号中的一个，则将错误信息压入服务端的用户栈顶。由于，错误信息是从服务端的用户构件传递给客户程序的，所以在执行步骤201和203时，客户端的代理和服务端的存根对调用参数的打包和解包并没有执行特殊的操作。随后，就可进行错误信息的传递了。在步骤204，判断上面的调用的结果，如果该结果属于特殊错误号中的一个，则执行步骤206，存根从服务端的用户栈顶取出错误信息；然后，进入步骤207，将从服务端的用户栈顶取出的错误信息添加在该调用结果，即该特殊错误号的后面，并将它们一起打包，即将调用结果和错误信息一并压缩在一个缓冲区中；如果调用结果不属于特殊错误号中的一个，即调用结果为成功返回值或为通用错误号时，则进入步骤205，收集调用结果并将该调用结果打包；打完包后，进入步骤208，系统将打包后的结果传递给代理，代理拿到结果后，在步骤209判断该结果是否属于特殊错误号中的一个；如果属于特殊错误号中的一个，则进入步骤211，执行解包操作，即从缓冲区中将错误信息解析出来，同时将错误信息添加到客户端的用户栈顶，然后进入步骤212整个调用过程结束；否则进入步骤210，直接执行解包操作，即从缓冲区中将调用结果解析出来，随后进入步骤212，完成对错误信息的传递。
权利要求
1.一种软件构件处理错误信息的方法，其特征在于，包括下列步骤构件方法调用时，若构件平台中预先定义的通用错误号能满足实际需要，则返回一个通用错误号；否则，返回一个特殊错误号，然后通过跨进程或跨机器调用过程，传递字符串或URL类型的错误信息；所述错误信息的传递过程如下判断方法调用的结果，如果该结果不属于特殊错误返回值中的一个，即调用结果为成功返回值或为通用错误号时，则服务端的存根将收集调用结果并将该调用结果打包；否则，从服务端的用户栈顶取出错误信息，将所述错误信息添加在该调用结果的后面，然后将其打包；随后，系统将打包后的结果传递给客户端的代理，代理拿到结果后，如果经判断该结果不属于特殊错误返回值中的一个，则执行解包操作，从缓冲区中将调用结果解析出来；否则，在执行解包操作的同时将错误信息添加到客户端的用户栈顶。
2.根据权利要求1所述的软件构件处理错误信息的方法，其特征在于，所述通用错误号是一个32位的整型，其第一位为1，每个通用错误号对应于构件平台中唯一的一个错误信息。
3.根据权利要求1所述的软件构件处理错误信息的方法，其特征在于，所述特殊错误号包括标示宽字符串类型的错误信息的错误号、标示ASCII字符串类型的错误信息的错误号和标示URL类型的错误信息的错误号。
全文摘要
本发明公开了一种软件构件处理错误信息的方法，包括以下步骤构件方法调用时，若构件平台中预先定义的通用错误号能满足实际需要，则返回一个通用错误号；否则，返回一个特殊错误号，通过跨进程或跨机器调用过程，传递字符串或URL类型的错误信息；传递错误信息时，首先判断方法调用结果，若该结果不属于特殊错误号中的一个，则收集调用结果并将其打包；否则，从服务端的用户栈顶取出错误信息，将其添加在该调用结果后面并打包；将打包后的结果传递给客户端的代理，代理拿到结果后，如果经判断该结果不属于特殊错误号中的一个，则进行解包；否则，在执行解包操作的同时将错误信息添加到客户端的用户栈顶。解决了由自定义错误号引起的问题。
文档编号G06F11/36GK101082878SQ200610027060
公开日2007年12月5日 申请日期2006年5月30日 优先权日2006年5月30日
发明者陈榕, 王晨辉, 沈金 申请人:上海科泰世纪科技有限公司