[omniORB] Processing DII Exceptions

[Peter Chase]

Hi,

We seem to be experiencing a change of behaviour from OmniORB, regarding
exceptions that happen in DII calls. I would like to check whether my
guesses are correct.

The snippet of our code is: -


...

try
{

...

vRequest->invoke();

...

CORBA::Environment_ptr pEnv = vRequest->env();
CORBA::UnknownUserException * pEx = (CORBA::UnknownUserException
*)pEnv->exception();
if (pEx == NULL)
{
// no exceptions raised - the call succeeded
corbaPrivate->fSuccess = TRUE;
}
else
{
// The exception actually thrown is hidden in an Any in the
UnknownUserException.
CORBA::Any any(pEx->exception());

...
}
}
catch (CORBA::SystemException &ex)
{
...
}

...


The code is assuming that the exception() will only ever contain a
UserException. It assumes that, if the operation invoked throws a
SystemException, then the invoke() call will throw that directly, not put
it in the exception().

Using the debugger, I can see that, when the operation invoked throws a
COMM_FAILURE SystemException, the above code to process a UserException is
running. It crashes with AccessViolation somewhere in "CORBA::Any
any(pEx->exception())".

Presumably, the crash is due to our casting a CORBA::SystemException* to a
CORBA::UnknownUserException*.

This crash occurs in OmniORB 4.1.0, but did not occur in OmniORB 3.0.4.

I notice that OmniORB 4.1.0 has a configuration parameter
diiThrowsSysExceptions default = 0. This suggests that OmniORB 4 will, by
default, do exactly what I am observing; that is, SystemExceptions do not
get thrown but instead end up in the exception().

I guess I can make the crash go away by changing this configuration
parameter. But I am curious to know why it did not crash in OmniORB 3.

Looking at Pure CORBA book, it suggests using _downcast() on the
CORBA::Exception, to try safely casting it to SystemException and then to
UserException. This looks like a better approach than twiddling the
configuration parameter, as the configuration parameter is Omni-specific,
isn't it?



(BTW I'll be removing the == NULL horror!)

[Duncan Grisby]

Post by Peter Chase
We seem to be experiencing a change of behaviour from OmniORB, regarding
exceptions that happen in DII calls. I would like to check whether my
guesses are correct.

Sorry for the long delay in replying to this...

[...

Post by Peter Chase
Using the debugger, I can see that, when the operation invoked throws a
COMM_FAILURE SystemException, the above code to process a UserException is
running. It crashes with AccessViolation somewhere in "CORBA::Any
any(pEx->exception())".
Presumably, the crash is due to our casting a CORBA::SystemException* to a
CORBA::UnknownUserException*.

Yes, I'm sure it is.

Post by Peter Chase
This crash occurs in OmniORB 4.1.0, but did not occur in OmniORB 3.0.4.
I notice that OmniORB 4.1.0 has a configuration parameter
diiThrowsSysExceptions default = 0. This suggests that OmniORB 4 will, by
default, do exactly what I am observing; that is, SystemExceptions do not
get thrown but instead end up in the exception().
I guess I can make the crash go away by changing this configuration
parameter. But I am curious to know why it did not crash in OmniORB 3.

The change is because at some point the CORBA spec was clarified to say
that system exceptions should be handled in the same way as user
exceptions in DII, where before omniORB threw system exceptions as
normal exceptions. Newer versions of omniORB adhere to the clarified
spec, but keep the option to throw system exceptions as exceptions for
backwards compatibility.

Post by Peter Chase
Looking at Pure CORBA book, it suggests using _downcast() on the
CORBA::Exception, to try safely casting it to SystemException and then to
UserException. This looks like a better approach than twiddling the
configuration parameter, as the configuration parameter is Omni-specific,
isn't it?

Yes, that's the best thing to do. _downcast will do the right thing.

Cheers,

Duncan.