river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Using an unchecked exception instead of RemoteException
Date Tue, 09 Jun 2015 12:45:02 GMT

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 <paawak@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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message