



3.11 Exceptions and Error Recovery
It's a good time to consider exceptions and recovery from errors. Remote
object creation and remote method call may cause exceptional situations
rather than successful completion. For example, if a remote host is down,
remote object creation will fail. In such case, an NetException will be
thrown by proxy object creation.
horb.orb.HORBException
has some subexceptions. The below is a list of exceptions.Since
HORBException is a subclass of RuntimeException, you may not catch or
declare HORBException or its subclasses explicitely. But, remember all
remote operation may throw HORBException. Usually exception handling
is required in practical applications.
- NetException (suclass of HORBException)
- This exception represents network related error. For example, host
not found, peer not respond, peer resets connection or Network connection
has broken. That is, the connection is no longer available and the proxy
object is not usable. You have to make a new proxy object and dispose the
first proxy object.
- RemoteException (subclass
of HORBException)
- An exception occurs in the remote method. RemoteException.toString()
returns exception message of the remote exception. "horb -v"
dumps stack trace when remote exception occurs. It's quite useful to know
where the exception occures. The proxy object is still usable.
- ProxyException (subclass
of HORBException)
- Signals failure to allocate a proxy object.
- Reconnection failure after object passing by reference.
- Foo_Proxy.class or Foo_Skeleton.class not found during passing an instance
of Foo. This exception means you should prepare proper *_Proxy and *_Skeleton
class for a remote object.
This exception occures only when the strict flag of IOCI is true. The
default is false. If the strict flag is false, ORB silently ignores the
errors. That means that an exception may occur when you use remote object
reference that was passed remotely. The proxy object is not usable after
occuring of this exception.
- NoMethodException
(subclass of HORBException)
- Failure to find a corresponding method to be called. The proxy object
is still usable, but the versions of proxy and skeleton may mismatch. You
should prepare proper proxy and skeleton.
- NoObjectException
(subclass of HORBException)
- Signals failure to find object to be called. This exception will be
throwon, if:
- no class found.
- no daemon object with such object name found.
The proxy object is not usable and no connection has made after this
exception.
- ArgumentException
(subclass of HORBException)
- Exception, for example null pointer access, occures in skeleton side
during passing arguments. The proxy object is no longer usable. Create
a new proxy object and dispose the errornous proxy object.
ArgumentException.toString() returns exception message of the remote
exception.
- HORB server always dumps stack trace when argument exception occurs.
IOCIException
Failure of IOCI or protocol error. This exception will be throwon,
when;
- Class major version mismatch between client's proxy and server's skeleton.
- IOCI's major version mismatch between client and server.
- IOCI class not found at the server side.
- Preamble of method call mismatch.
The proxy object is not usable after this exception. You should get
rid of a reason of the error.
NoPermissionException
Access permission error. This exception is raised, if:
- Client's host or user is not allowed to access the object or the method.
- Password mismatch.
The proxy object is usable.
HORBException
General failure. The exception string describes the reason.
Exception.getMessage() returns a detail message of the exception.
When a proxy object become not usable, user have to dispose the proxy
object. You can call _release()
of the proxy object to release the connection immediately. The remote object
is automatically removed if no other connections are active.
The situation whereby a proxy object becomes unusable is mainly due
to loss of synchronization between the proxy object and a corresponding
skeleton object. If you want to continue to use the same remote object,
you can reset the synchronization by creating a new connection and a new
skeleton object in a new thread.
Remote_Proxy remote = new Remote_Proxy(url);
try {
remote.op1();
} catch (HORBException e) {
Remote_Proxy remote2 = new Remote_Proxy(remote._getObjectURL());
remote._release();
remote = remote2;
// now you can use remote again
}
A future version will become more durable.