client-side can't catch any exception server-side throwed....

TAO VERSION: 1.2.1
ACE VERSION: 5.2.1

HOST MACHINE and OPERATING SYSTEM: x86(Pentium4), RedHat Linux 3.2.2
Linux Kernel 2.4
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc version 3.2.2 20030222
(Red Hat Linux 3.2.2-5)

AREA/CLASS/EXAMPLE AFFECTED: example

DOES THE PROBLEM AFFECT: EXECUTION


SYNOPSIS: my application

DESCRIPTION: Client code can't catch any exception.
In the example code below, I thorougly examined that the
server side throwed OccupiedPort or
InvalidPort, UnknownPort exception through the network packet
tool('ethereal').
But the client can't catch any exception. It just show
"Program received signal SIGABRT, Aborted" message.
On purpose, I examine connectPort, getPort function with
wrong argument, but client can't catch any
of it's exception. Even 'catch(...) clause didn't works'. I
can't understand why?


/* IDL */

.....

interface Port {
exception InvalidPort {
unsigned short errorCode;
string msg;
};

exception OccupiedPort { };

void connectPort ( in Object connection, in string connectionId)
raises (InvalidPort,OccupiedPort);

void disconnectPort ( in string connectionId )
raises (InvalidPort);
};
interface PortSupplier {
exception UnknownPort { };

Object getPort ( in string name )
raises (UnknownPort);
};

....

/* client side code */
void connect(std::string usesport_resource_IOR, std::string useid,
std::string providesport_resource_IOR,std::string provideid, std::string
connectionID ) {
try {
cout << "begin of connect function" << endl;
ORBFactory *factory = ORBFactory::Instance();
CORBA::Object_var _useport_resource =
factory->orb->string_to_object(usesport_resource_IOR.c_str()) ;
CF::PortSupplier_var _useport_resource_portsuppliertype =
CF::PortSupplier::_narrow(_useport_resource.in());

CORBA::Object_var _provideport_resource =
factory->orb->string_to_object(providesport_resource_IOR.c_str( ));
CF::PortSupplier_var _provideport_resource_portsuppliertype =
CF::PortSupplier::_narrow(_provideport_resource.in ());
CORBA::Object_var _useport =
_useport_resource_portsuppliertype->getPort(useid.c_str());
cout << "provideid.c_str() = " << provideid.c_str() << endl;
CORBA::Object_var _provideport =
_provideport_resource_portsuppliertype->getPort(provideid.c_str());

CF::Port_var _useportporttype = CF::Port::_narrow(_useport.in());
_useportporttype->connectPort(_provideport.in(), connectionID.data());
// this may throw OccupiedPort, InvalidPort
cout << "connected successfully!!!" << endl;
}catch(CF::Port::OccupiedPort ex1) {
cout << "CF::Port::OccupiedPort raised! " << endl;
}catch(CF::Port::InvalidPort ex2) {
cout << "CF::Port::InvalidPort raised!" << endl;
}catch(CF::PortSupplier::UnknownPort ex3) {
cout << "CF::PortSupplier::UnkwownPort raised!" << endl;
}catch(CORBA::Exception ex4) {
cout << "CORBA::Exception raised!" << endl;
}catch (...) {
cout << "Yes, I got you!" << endl;
}
}




....

"À̹ü¼®" <aw2310@yahoo.co.kr> wrote in message news:<d09190da631b6bda76cfd58698138466@news.terane ws.com>...
>[Server throws an exception, but the client cannot catch it and instead
>the client crashes with SIGABRT]

A few years ago, I had a similar problem with a different CORBA product
on Solaris, using the Sun compiler. After a week of banging my head against
the wall, I eventually discovered that my environment variables were set up
inconsistently and I was using a new version of the Sun compiler but
linking against an older version of the compiler's runtime library.
This inconsistency prevented exceptions from being caught.

Another possible cause of your crashes that there you have a
bug in your catch clauses. You are catching exceptions by value
when instead you should catch them as const references. For example,
instead of:

catch(CORBA::Exception ex4)

use:

catch(const CORBA::Exception & ex4)

My C++ knowledge is not expert enough to know why the "const" keyword
has to be there, but I was advised of this by somebody else who knows
C++ better so I just follow their advice. However, the reference ("&")
is vital because without it you can get what is called "slicing" of
the exception. A good C++ book should have a discussion about slicing
and why it is dangerous.


Regards,
Ciaran.

ciaran.mchale@iona.com (Ciaran McHale) writes:

> "À̹ü¼®" <aw2310@yahoo.co.kr> wrote in message news:<d09190da631b6bda76cfd58698138466@news.terane ws.com>...
>>[Server throws an exception, but the client cannot catch it and instead
>>the client crashes with SIGABRT]
>
> A few years ago, I had a similar problem with a different CORBA product
> on Solaris, using the Sun compiler. After a week of banging my head against
> the wall, I eventually discovered that my environment variables were set up
> inconsistently and I was using a new version of the Sun compiler but
> linking against an older version of the compiler's runtime library.
> This inconsistency prevented exceptions from being caught.

A similiar problem exists with duplicate symbols in libc and libstdc++
on Linux. Make sure to invoke the linker as "g++" not "gcc".

If that doesn't help:

SIGABRT may be the consequence of the unexpected_handler to be invoked
which by default calls std::terminate. The unexpected_handler is
called amongst other reasons if an exception thrown by a C++ function
violates the exception specification of the function i.e. the function
has a throw clause and the exception is not in the function's throw
clause. Maybe that's the problem. See the documentation of the -Ge
flag of the TAO IDL-Compiler.

It shouldn't the cause of your problem, but as as ciaran already
pointed out, you better catch exception by reference to prevent
slicing the exception.

Catching exceptions as const prevents you from modifying the catched
exception, but I've never seen code up to now which failed because it
had changed the contents of an exception. After all exceptions a very
short-lived objects.

BTW: There is a specialized newsgroup for TAO called
comp.soft-sys.ace. If you don't succeed you should repost there.

Best regards, Matthias