I agree wholeheartedly with Palash Ray. The problem with this principle
of "RemoteException" in River, which I have never agreed with, is twofold:
* The most common and correct interpretation of checked / unchecked
exceptions in Java, seen in the light of design-by-contract, is
o Unchecked exceptions (RuntimeException) are an abstraction for
an unexpected *system error* at that level of granularity. This
could range from a code bug (NullPointerException) to some
underlying database server being down. Neither are the caller's
fault, and the caller should not be forced to handle the
individual failure possibilities by *type* - because literally
anything can go wrong. Underlying comms failure
(RemoteException) logically falls in this class of service, but
doesn't by type (i.e. it is not a RuntimeException)
o Checked exceptions are a signal for *refusing a service* because
a *precondition was not met* (e.g. withdrawing money from an
account with no funds). This is expected, and part of the normal
operation of the system. The client should, as part of engaging
with a contract, have a plan of action for all refusal
scenarios, and the compiler helps us here with checked exceptions.
* Interfaces are, and should be, designed based on the pure
functionality that they provide. I should not have to add
SQLException to an interface because some implementation uses a SQL
database, and similarly, I should not add RemoteException because
some implementation is a proxy to a remote object. In both cases, at
that particular level of granularity, the exception denotes an
unexpected System error. It's nice to classify the nature of these
errors, but for that, the RuntimeException could wrap the
RemoteException or SQLException as 'cause'.
Plug-ability of components are severely compromised if I have to change
my interface because of an implementation change (i.e. remote to local).
I understand that it's useful to "remind" people of things, but the
thing that should, rather, be reminded of is whether a service exhibits
call-by-reference of call-by-value semantics (regardless of whether it's
"remote" or not). The wholesale move away from traditional
object-oriented style to services-oriented style means that very few
people write services with expected call-by-reference semantics in
anyway, so I don't think this is a significant problem.
If I could have one feature in River, it would be the following:
* Make RemoteException extend RuntimeException (i.e. be unchecked)
* Introduce (or use, if present) a mechanism - annotation? - to
indicate by-ref/by-value calling semantics (on inputs/outputs of a
service)
* It's perfectly fine to still enforce service implementations to
declare RemoteException, as a "tag" / "reminder", but honestly, it's
not the client's concern. Depending on the reliability requirements
of the client, they need to handle unexpected failure in anyway, and
RemoteException is functionally no different than, say, a NullPointer.
Many people may not agree with this take on the matter. I'm merely
reflecting on many years of building pluggable, services-oriented
systems in Java. This is the one flaw in River that propagates up to a
"design" (contract, interface) level.
regards,
Dawid Loubser
On 09/06/2015 14:45, Greg Trasuk 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.
>
