0

I have one method in IDL(test.idl) file: 

bool login(in string name, in string cipher) raises (AuthenticationException);

AuthenticationException is declared an exception in my IDL files. Then I use tao_idl to generate skeleton with below parameters: 

-Wb,stub_export_macro=BASE_STUB_Export -Wb,stub_export_include=base_stub_export.h -Wb,skel_export_macro=BASE_SKEL_Export -Wb,skel_export_include=base_skel_export.h -GC

However, the generated login method in testS.h is like: 

virtual ::project::UserContext * login (
  const char * name,
  const char * cipher) = 0;

and testI.h: 

virtual
 ::project::UserContext * login (
  const char * name,
  const char * cipher);

This is strange to me. Because method declaration missing AuthenticationException exception. I believe that the method should be like: login(..) throw(AuthenticationException) in which custom exception, instead of CORBA standard exception, is thrown in business logic and client stub can catch these exception.

Is there something wrong in my tao_idl parameters?

shijie xu
  • 1,975
  • 21
  • 52

1 Answers1

1

No, there is nothing wrong with your tao_idl parameters, this is how the IDL to C++ mapping is defined. Older versions of IDL to C++ did use exception specifications in C++, but the recent ones don't, see the OMG IDL to C++ mapping which you can obtain from http://www.omg.org/spec/CPP.

Also the IDL to C++11 language mapping doesn't use exception specifications, this more modern C++ language mapping is also available from the OMG, see http://www.omg.org/spec/CPP11.

Your IDL method and the generated signature don't match, with IDL to C++11 your login method (with a boolean return type) in IDL looks like

virtual bool login (const std::string& name, const std::string& cipher) = 0;
Johnny Willemsen
  • 2,942
  • 1
  • 14
  • 16
  • Thanks @Johnny. You are right.The dismatch is copy&paster error. If there is no more exception specification for skeleton, can i still raises custom exception(AuthenticationException) in servant login implementation? Meanwhile, the exception can still be caught at client as: try{} catch(AuthenticationException){} ? – shijie xu Dec 01 '13 at 21:11
  • 1
    Yes, the raise and catch of user exceptions still works, in order to do that correctly you will need to specify the user exception in IDL, else it will not work – Johnny Willemsen Dec 02 '13 at 08:26