If you’re making remote calls, then there is a definite chance that you will have communications errors. So, it’s probably not a good idea to just hide the errors, especially since the application handling/response to a communications error really should be different from the handling of an applications error. With a communications error, (1) it may be worthwhile to just try it again later, (2) you don’t really know whether the other end processed the call, so the response is somewhat indeterminate. As a result, we typically don’t recommend using unchecked exceptions. The Remote interface and the IOException that’s thrown from a remote call is meant to remind developers that things are different on a network.
For more thoughts on this, you should read “A Note on Distributed Computing” (http://eecs.harvard.edu/~waldo/Readings/waldo-94.pdf <http://eecs.harvard.edu/~waldo/Readings/waldo-94.pdf>). This paper really forms the basis of the Jini philosophy, along with the Eight Fallacies (http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing <http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing>). Having said that, if you really want to use unchecked exceptions, just write a smart proxy that converts the IOExceptions to some runtime exception (you could probably even do this generically using “java.lang.reflect.Proxy”), and register the smart proxy with Reggie rather than the actual exported endpoint. Cheers, Greg Trasuk > On Jun 8, 2015, at 3:49 PM, Palash Ray <paa...@gmail.com> wrote: > > Devs, > > I have long struggled with the fact that we have to declare a > RemoteException for every Remote method that I expose. I do not like > the try catch, which is pretty verbose, and in our application, when > we do encounter a RemoteExceotion, its always fatal, and there is no > way we can, or want, to recover from it. > > I would like to explore the possibility of using an unchecked > exception, instead. > > I guess it would work if I extend the BasicIlFactory and override the > method, which checks for the presence of the RemoteException in the > remote method. However, it seems to me to be a bit hacky. > > Is there an elegant solution to this problem? Thoughts please. > > Thanks, > Palash.
