checking for org.omg.CORBA.OBJECT_NOT_EXIST

[donalm...@yahoo.co.uk]

Hi,

I'm writing a java CORBA client, using the Visibroker ORB. Sometimes
when I call methods on the remote object references I get the following
exception

org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: OMG minor code: 0 completed:
No

Is there some way that I can check beforehand whether this exception
will be thrown, i.e. whether the remote object still exists? I thought
that I could do it like this:

if (myRef._non_existent()) {

// get a new myRef
}

myRef.doRemoteMethod();

But I've found that _non_existent() throws exceptions. Is there a
better way to check for the state that causes an OBJECT_NOT_EXIST
exception?

Regards,
Dan

[ke_...@yahoo.com]

We should say thanks to OMG that made this change in 2.3 (or earlier?).
Now, your best around is to be write a wrapper that catches exceptions
and return true.

For visibroker, I recall it has a property you can set that will force
the ORB to be backward compatible to CORBA 2.2, namely, non_existent()
returns true, instead of throwing a exception, when it fails to connect
to the server.

Regards,
Ke

>
> Regards,
> Dan

[Jonathan Biggar]

ke_...@yahoo.com wrote:
> We should say thanks to OMG that made this change in 2.3 (or earlier?).
> Now, your best around is to be write a wrapper that catches exceptions
> and return true.
>
> For visibroker, I recall it has a property you can set that will force
> the ORB to be backward compatible to CORBA 2.2, namely, non_existent()
> returns true, instead of throwing a exception, when it fails to connect
> to the server.

I consider that broken behavior, which is why the standard was clarified
in 2.3 to allow non_existent() to throw exceptions.

non_existent() returning true when it can't contact the server is likely
returning a lie.

Just write your own wrapper function that calls non_existent(), catches
the exceptions you want, and returns different error codes for different
exceptions. Once you've done that, you can reuse that code everywhere
without having to write lots of catch() blocks.

--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org

[ke_...@yahoo.com]

Jonathan Biggar wrote:
> Just write your own wrapper function that calls non_existent(), catches
> the exceptions you want, and returns different error codes for different
> exceptions. Once you've done that, you can reuse that code everywhere
> without having to write lots of catch() blocks.

Then, you would end up with exactly same "lots of" switch/case blocks
:).

Regards,
Ke

[Jonathan Biggar]

ke_...@yahoo.com wrote:
> Jonathan Biggar wrote:
>> Just write your own wrapper function that calls non_existent(), catches
>> the exceptions you want, and returns different error codes for different
>> exceptions. Once you've done that, you can reuse that code everywhere
>> without having to write lots of catch() blocks.
>
> Then, you would end up with exactly same "lots of" switch/case blocks
> :).

Not if you design the error codes right, or make predicate functions
that you can reuse that translate the error code to a boolean value.

[ke_...@yahoo.com]

Jonathan Biggar wrote:
> ke_...@yahoo.com wrote:
> > Jonathan Biggar wrote:
> >> Just write your own wrapper function that calls non_existent(), catches
> >> the exceptions you want, and returns different error codes for different
> >> exceptions. Once you've done that, you can reuse that code everywhere
> >> without having to write lots of catch() blocks.
> >
> > Then, you would end up with exactly same "lots of" switch/case blocks
> > :).
>
> Not if you design the error codes right, or make predicate functions
> that you can reuse that translate the error code to a boolean value.
>

As long as your wrapper "returns different error codes for different
exceptions".

Here is an example:

original code with many try/catch:

try {
....
}
catch(exception a) {
handle_exception_a(...);
}
catch(exception b) {
handle_exception_b(...);
}
...

wrapper that "returns different error codes for different exceptions":
...

int wrapper() {
...
try {
....
}
catch(exception a) {
return error_code_a;
}
catch(exception b) {
return error_code_b;
}
...
}

Use of this wrapper:

...
switch(wrapper()) {
case error_code_a: handle error a; break;
case error_code_b: handle error b; break;
...
}

Regards,
Ke

[Jonathan Biggar]

ke_...@yahoo.com wrote:
>>>> Just write your own wrapper function that calls non_existent(), catches
>>>> the exceptions you want, and returns different error codes for different
>>>> exceptions. Once you've done that, you can reuse that code everywhere
>>>> without having to write lots of catch() blocks.
>>> Then, you would end up with exactly same "lots of" switch/case blocks
>>> :).
>> Not if you design the error codes right, or make predicate functions
>> that you can reuse that translate the error code to a boolean value.
>>
>
> As long as your wrapper "returns different error codes for different
> exceptions".

You're missing my point.

Or:

bool error_codes_i_care_about(error code e) {
switch (e) {
case error_code_a:
case error_code_c:
return true;
default:
return false;
}
}

error_code wrapper(CORBA::Object_ptr obj) {

try {
....
}
catch(exception a) {
return error_code_a;
}
catch(exception b) {
return error_code_b;
}
...
}

bool wrapper(CORBA::Object_ptr obj, bool (*predicate)(errror_code)) {
return predicate(wrapper(obj));
}

...
if (wrapper(obj, error_codes_i_care_about)) {
// handle errors I care about
else
// do something else
...