This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Checked or unchecked with remote objects

Posted by Mike Mannion on 08 Jul 1998, 1:07 AM

> Bill, I like your advice that checked exceptions should be thrown when you expect the client will know how to and should deal with them, and unchecked exceptions should be thrown indicating incorrect usage.
> One issue I deal with a lot is implementing classes in a distributed environment. When I define an interface for these classes, I have debated whether it is better to define NetworkException faults as checked or unchecked exceptions. This is certainly the case where you expect that the client should deal with these types of faults. But, then you have to ask, will the immediate client know HOW to deal with them? Or will someone higher up his stack know how to? The simple answer to this question is that the immediate client should simply rethrow the exception if this is the case. But, this approach tends to clutter up a lot of code that you may not want to be network aware. Often the immediate client of the remote object is not aware that the object is really remote. i.e. consider a File I/O system where the underlying implementation is an NFS. In applications, network fault handlers are typically implemented very high up in the application stack, because they often require user interaction to fix.
> Also, the rarity of your exception depends on your network. If you're on an Ethernet LAN, messages between nodes are extremely reliable, and somewhat fast - so a remote method invocation is almost as reliable as invoking a local method. (Someone could pop out your memory chips almost as easily as unplugging you from the LAN). However, if you're communicating between clients over a modem, network faults occur very frequently, and clients typically have to know the difference since modems are so slow.
> RMI forces you to define a RemoteException for every method, whereas some other ORBs like Voyager allow you to define your preferred exception model.
> So, my question is: checked or unchecked?

I am currently designing and implementing the client
architecture of a data maintenance utility as part of a major
banking application. The client is CORBA-based and has a GUI.

The question I asked myself when deciding whether or not to use
checked or unchecked exceptions was this: Is it reasonable that
the client application terminates just because of the occurrence
of a network or ORB error? Answer (in my case): Certainly not.
Our users must always be informed of such occurrences (however
unlikely), and the method of informing the user should be in
line with the rest of the GUI i.e. message box. In other cases,
program termination may be acceptable.

As a result, we use checked exceptions to oblige someone in the
calling chain to deal with the problem.

Note: If the immediate caller cannot deal with the problem
there is no need to re-throw the exception. He simply needs
to declare the exception (or some superclass there-of) in
his own method's signature.

The Java/CORBA language bindings also specify two hierarchies of
exception which are descendants of RuntimeException and Exception
respectively: CORBASystemException and CORBAUserException,
so it is possible that unchecked exceptions are thrown from
somewhere in or beyond the proxy object.

Because of what was concluded above, we now trap ALL CORBA
exceptions at the point of proxy method invocation.
A locally defined *checked* exception is instantiated and
initialised with the original exception (effectively wrapping
it). This checked exception is then thrown and someone in
the calling chain *has* to deal with it.

MM