[omniORB] Standard ?

[Dietmar May]

Mark,

> > The Environment parameter is an optional value, required only for
> > those
> > ORB implementations which support compilers that don't handle C++
> > exceptions. omniORB uses C++ built-in exception handling on all of
> > the
> > platforms (to the best of my knowledge), and therefore does not need
> > an
> > Environment variable. The use of Environment is ORB-dependent (see
> > CORBA
> > 2.1 sec 16.17 p16-45).
>
> True, but I believe the spec. still refers to it as an "implicit
> parameter". (Haven't checked 2.1, but 2.0 did do so.) So, some ORB
> vendors implement it as such, whereas others simply don't provide it at
> all.

I haven't been able to find any reference in the CORBA spec which would 
REQUIRE an ORB implementation to support an Environment parameter. (I've 
got to admit that I haven't looked TOO hard, though). The wording for 
16.17 seems to indicate that it is not needed if a compiler supports 
native C++ exceptions:

"In an implementation that does not support real C++ exceptions, an 
output Environment parameter is the last argument following all 
operation-specific arguments, and following the context argument if 
present."

The implication is that an implementation that does support real C++ 
exceptions does not need this parameter.

The wording for 17.4 is indeterminate:

"Environment provides a vehicle for dealing with exceptions in those 
cases where true exception mechanics are unavailable or undesirable (for 
example in the DII)."

After years of supporting TRY/CATCH type macros within code to support 
non-exception handling compilers, I find it quite refreshing to see 
widespread support for C++ native exception handling in all of the major 
C++ compilers, and to know that this will no longer be an issue for OUR 
projects. However, I strongly appreciate the needs of those supporting 
systems where true exception handling is not available.

> But since some ORBs still don't use native exception handling (e.g.,
> Nortel's RCP-ORB) it means that your server/object code needs to
> support
> both types of signatures (assuming you want to make it "portable").
>
> We have similar macros to you to try to get round this, but at present
> omniORB doesn't provide an Environment class implementation. When it
> does, I'd assume that the server stub code will have to be made
> sufficiently intelligent that it can recognise receiving an Environment
> in the call signature for a method and pack up any exceptions into it
> the object may throw, otherwise the client won't be able to handle 
them.

Ultimately, if your source code needs to support both ORB/compiler 
implementations which use native C++ exceptions, and those which don't, 
you have A LOT of work to do. There is the mapping between TRY/CATCH 
style macros, which (I believe) are ORB-vendor dependent (then add in 
supporting TRY/CATCH macros from ObjectStore or other OODBM vendor!), 
passing along the environment variable to any function which is called 
that might perform try/catch, etc. All in all, not a trivial task.

> For true language independence this will need to be done anyway, since
> clients written in C, for example, will be sending Environments all the
> time.

It is my understanding that at the client/server boundary, the ORBs 
should handle any necessary conversion between language-specific 
implementation issues, such as exceptions. As such, a server written in 
C++, and using native C++ exceptions, should be able to throw an 
exception, have it caught by the server ORB, converted into whatever 
exception class it maps to, and passed back to the client via IIOP. For a 
client written in C, it would be converted into its C mapping, and passed 
up the calling chain via the Environment parameter until it was handled. 
But, I haven't tried mixed language development, so perhaps you have more 
experience than I in this.

Regards,
Dietmar May
Software Architect
Object Workshops, Inc.
http://www.object-workshops.com