Thanks a lot Gregg. This is certainly an interesting idea worth exploring. I will let you know how it goes.
Thanks, Palash. On Tue, Jun 9, 2015 at 8:45 AM, Greg Trasuk <tras...@stratuscom.com> wrote: > > 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. > >
