[omniORB] FW: May not return NULL???

Gary Duzan gduzan at bbn.com
Wed Nov 26 10:26:27 GMT 2003


In Message <3FC49B88.7030104 at canama.net> ,
   Carlos <carlos at canama.net> wrote:

=3D>P=E1ncz=E9l Levente wrote:
=3D>> Hello!
=3D>> =

=3D>> I have a function in an interface wich simply reads the name of an o=
bject instance:
=3D>> string GetName();
=3D>> which generates the C++ code
=3D>> char *GetName();
=3D>> My problem is that the name of an object is allowed to be _anything_
=3D>>but the object might be in a state where Name is not initialised yet.=
 To
=3D>>indicate this internally the server uses NULL pointers, so I'd really
=3D>>like this function to be lagally able to return NULL.
=3D>>
=3D>> I do understand that this would be a problem, when I'm interfacing
=3D>>other languages, where there is no such external string value like
=3D>>a NULL pointer. Though it would be acceptable for me if in case of
=3D>>returning a NULL omniORB sent an exception making the client aware of=
 the
=3D>>non-marshalable value. Now the case is that when omniORB is beginning
=3D>>to marshal the value it generates a segfault, causing not only the OR=
B
=3D>>subsystem of the server but the whole server to crash.
=3D>>
=3D>> Please note that the last thing I would like to change is the IDL.
=3D>
=3D>No a string f() doesn't return NULL, you must return an empty string o=
r =

=3D>throw and exception like NullValue, but you must indicate it in idl:
=3D>
=3D>exception NullValue;
=3D>string GetName() raises (NullValue);
=3D>
=3D>I think this is correct.

   Often in this case I will avoid changing the IDL by cheating (somewhat)
and raising some sort of CORBA::SystemException, which any method can
raise. Something like CORBA::BAD_INV_ORDER or CORBA::NO_RESOURCES or even
CORBA::TRANSIENT. Use at your own risk, of course.

					Gary Duzan
					BBN Technologies
					A Verizon Company





More information about the omniORB-list mailing list