On 11/06/2015 16:24, Greg Trasuk wrote:
>> * 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.
> I disagree. In my experience, communications exceptions need to be carefully
> considered by the service consumer.
Doesn't that effectively leave only two options?
* Remote services can only implement, and be called via, contracts
that were designed at the time that I decided this will be a remote
service. No re-purposing or adapting of existing functionality to,
say, a new remote service. (i.e. I used to call a local database,
now I'm going to call a Jini service).
* "Just in case", make all methods on all contracts ever throw
RemoteException - although some frameworks like EJB 3.x won't like
that for certain types of services. Applying something to
everything, and to nothing, are semantically equivalent.
Interfaces are supposed to promote plug-ability, right? I agree that
remote services are a leaky abstraction. Furthermore, Java's limited
type system does not give us elegant ways to re-use, say, the "business
semantics" of an interface in different contexts (such as, one that make
remote method calls). Because of this, I personally would rather have
the ability to strongly re-use interfaces in all contexts, across all
implementation technologies, where possible.
If, at a given level of granularity, we strictly apply the semantic that
checked exceptions are for *service refusal* (precondition not met), and
RuntimeException and Error for *syst**em failure* (postcondition not
met, not caller's fault), things are a whole lot simpler in my opinion
and experience.
Anyway, this has just been a big pain point for me all these years with
Jini/River. It has nothing to do with the "fallacies of distributed
computing", and everything with re-use, and the separation of
functionality from implementation technology in Java interfaces.
If it were up to me, I would introduce an "UnexpectedRemoteException"
and/or "UnexpectedIOException" which both extend RuntimeException, and
which are understood by River components in addition to the usual
checked [Remote/IO]Exception - which, by defintion, is "expected". Then,
instead of arguing about one solution for an opinionated framework, the
users of the framework can choose, experiment, etc. I feel that River,
as infrastructure, should impede as little as possible, and a checked
RuntimeException is demonstrably limiting to e.g. interface re-use.
warm regards,
Dawid Loubser
