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
Replies:
|