Orber(Erlang ORB)在TAO orb抛出时无法捕获用户定义的异常

我有一个C++ CORBA服务器,它实现了抛出用户定义的异常的接口.

当客户端和服务器都在C++中实现时(使用TAO orb和omniORB进行测试),我很容易捕获到特定的异常.

但是当我从Erlang(使用orber)调用相同的方法时,异常显示为一般异常,而不是特定的用户定义异常.

为了测试这个,我只使用了一个简单的IDL -

interface Messenger {

    exception cirrus_error{
            short error_code;
            string error_desc;
    };

    boolean send_message(in string user_name,
                       in string subject,
                       inout string message) raises (cirrus_error);
};

如果服务器和客户端都在C++中 - 我得到的异常是(对于测试我将其编码为始终抛出用户异常)

CORBA exception: cirrus_error (IDL:Messenger/cirrus_error:1.0)

但是当通过Erlang调用时 - 我得到了 -

** exception throw: {'EXCEPTION',{'UNKNOWN',[],1330446337,'COMPLETED_MAYBE'}}
 in function  corba:raise/1

在说明Orber应用程序以启用正确行为时,是否需要执行一些特殊操作？

编辑 - 这是我从erlang调用服务器的方式 -

在Erlang提示符下,这就是我所做的 -

1> orber:jump_start().

2> O = corba:string_to_object(IORStr).

3> 'Messenger':send_message(O, "s", "t", "f").
** exception throw: {'EXCEPTION',{'UNKNOWN',[],1330446337,'COMPLETED_MAYBE'}}
     in function  corba:raise/1 

Steve Vinosk.. 5

在调用方法之前,需要将IDL定义注册到orber接口存储库(IFR)中.messenger.idl例如,如果您的IDL文件已命名,则编译它会创建oe_messenger.erl提供该oe_register/0功能的文件.调用它将有关用户定义的异常的信息注册到IFR中,orber的CDR解码用于正确解码包含该异常的任何响应:

1> orber:jump_start().
...
2> ic:gen(messenger).
Erlang IDL compiler version 4.4
ok
3> make:all().
Recompile: Messenger
Recompile: Messenger_cirrus_error
Recompile: oe_messenger
oe_messenger.erl:65: Warning: function oe_get_top_module/4 is unused
oe_messenger.erl:91: Warning: function oe_destroy_if_empty/2 is unused
up_to_date
4> oe_messenger:oe_register().
ok
5> M = corba:string_to_object(IORStr).
...
6> 'Messenger':send_message(M, "a", "b", "c").
** exception throw: {'EXCEPTION',{'Messenger_cirrus_error',"IDL:Messenger/cirrus_error:1.0",
                                                           1234,"yep, an error"}}
     in function  corba:raise/1 (corba.erl, line 646)

更新:在orber中需要额外的IFR注册步骤的原因,尽管在C++ ORB中很少需要,但是由于CORBA规范的一些灵活性以及C++ ORB开发传统.在最初的CORBA规范,部分是静态和动态语言阵营之间的一种折衷.动态阵营坚持IFR在规范中,因为他们需要它在运行时检索类型信息(显然他们得到了他们的愿望,因为它一直是CORBA的一部分),但静态阵营认为IFR是不必要的,因为所有必要的类型信息可以用从IDL定义生成的C/C++代码进行编码.传统上,C++ ORB开发社区遵循代码生成方法,并将IFR视为可选的运行时组件,此问题中使用的C++ ORB cirrus_error从生成的存根和骨架中检索有关用户定义的异常的信息.但是用其他语言编写的ORB,例如Smalltalk和Erlang,已经选择使用IFR作为ORB运行时的正常组件,因此它们需要将类型信息注册到IFR中,以便ORB运行时可以使用它.但是,在Erlang中肯定可以生成有关用户定义的异常到存根/骨架的信息,并让运行时从那里检索它.

在调用方法之前,需要将IDL定义注册到orber接口存储库(IFR)中.messenger.idl例如,如果您的IDL文件已命名,则编译它会创建oe_messenger.erl提供该oe_register/0功能的文件.调用它将有关用户定义的异常的信息注册到IFR中,orber的CDR解码用于正确解码包含该异常的任何响应:

1> orber:jump_start().
...
2> ic:gen(messenger).
Erlang IDL compiler version 4.4
ok
3> make:all().
Recompile: Messenger
Recompile: Messenger_cirrus_error
Recompile: oe_messenger
oe_messenger.erl:65: Warning: function oe_get_top_module/4 is unused
oe_messenger.erl:91: Warning: function oe_destroy_if_empty/2 is unused
up_to_date
4> oe_messenger:oe_register().
ok
5> M = corba:string_to_object(IORStr).
...
6> 'Messenger':send_message(M, "a", "b", "c").
** exception throw: {'EXCEPTION',{'Messenger_cirrus_error',"IDL:Messenger/cirrus_error:1.0",
                                                           1234,"yep, an error"}}
     in function  corba:raise/1 (corba.erl, line 646)

更新:在orber中需要额外的IFR注册步骤的原因,尽管在C++ ORB中很少需要,但是由于CORBA规范的一些灵活性以及C++ ORB开发传统.在最初的CORBA规范,部分是静态和动态语言阵营之间的一种折衷.动态阵营坚持IFR在规范中,因为他们需要它在运行时检索类型信息(显然他们得到了他们的愿望,因为它一直是CORBA的一部分),但静态阵营认为IFR是不必要的,因为所有必要的类型信息可以用从IDL定义生成的C/C++代码进行编码.传统上,C++ ORB开发社区遵循代码生成方法,并将IFR视为可选的运行时组件,此问题中使用的C++ ORB cirrus_error从生成的存根和骨架中检索有关用户定义的异常的信息.但是用其他语言编写的ORB,例如Smalltalk和Erlang,已经选择使用IFR作为ORB运行时的正常组件,因此它们需要将类型信息注册到IFR中,以便ORB运行时可以使用它.但是,在Erlang中肯定可以生成有关用户定义的异常到存根/骨架的信息,并让运行时从那里检索它.