[Ace-users] [tao-bugs] How does DII report a user exception?

[Johnny Willemsen]

Hi,

Thanks for using the PRF form. There is a bugzilla entry to get the env()
call back, see http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1621

Regards,


Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl  

*** Integrated compile and test statistics see
http://scoreboard.theaceorb.nl ***
*** Commercial service and support for ACE/TAO/CIAO             ***
*** See http://www.theaceorb.nl/en/support.html                 ***



"Hans Utz" <hans.utz at nasa.gov> wrote in message
news:<mailman.3516.1201908264.5286.tao-bugs at mail.cse.wustl.edu>...
>      TAO VERSION: 1.6.2
>      ACE VERSION: 5.6.2
> 
>      HOST MACHINE and OPERATING SYSTEM: Linux RH Workstation 5
>      COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc (GCC) 4.1.2
> 
>      THE $ACE_ROOT/ace/config.h: config-linux.h
>      THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
>        platform_linux.GNU
>      AREA/CLASS/EXAMPLE AFFECTED: DII
> 
>      DOES THE PROBLEM AFFECT: EXECUTION
> 
>      SYNOPSIS: How does DII report a user exception?
> 
>      DESCRIPTION:
> 
> When a DII generated Request returns with an exception (from the list 
> ofspecified exceptions), a UnknownUserException is thrown by invoke(). I 
> don't know if this is correct or not, the standard is not very verbose 
> of that issue...
> 
> Any example code I found uses the env() call, to query exceptions, but 
> this was deprecated in TAO a while ago. - So how can I actually retrieve 
> the exception thrown by the servant?
> 
>      RELATED:
> 
> The Any holding return values for a DII invoke() call, contains tk_void 
> for methods returning void. APCP states in 16.3.1, that tk_void can 
> never appear as part of an any. - Well, I guess it makes perfect sense 
> in this case for the Any to hold tk_void. - But is this allowed by the 
> standard (and therefore portable)? And if so, how do I put a tk_void 
> into an any?
> 
> 
> Thanks,
> Hans
>