river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Using an unchecked exception instead of RemoteException
Date Fri, 12 Jun 2015 15:32:54 GMT
One of the primary things in software design is to place services into a service layer.  There
should be service failure exceptions and those should be distinctly different from “transport”
or “implementation” exceptions.  If your code has “RemoteException” visible in the
business logic, then you’ve probably not placed the services into a service layer so that
you can properly manage implementation of communications, separate from the service is not
reachable, usable, working states.

Once you have a service layer, then you have the opportunity to “change” the service implementation
to use varied technologies, or at least provide a hidden retry strategy that you can perfect
in “one place” instead of having it all over the place.

Jini’s documentation and much of the things circulating on the internet, typically avoid
any indication of using a service layer.  Instead, the service interfaces with Remote on them,
are all at the forefront of the visible code structure.

Gregg Wonderly

> On Jun 11, 2015, at 10:29 PM, Palash Ray <paawak@gmail.com> wrote:
> My two cents:
> I am in favour of having runtime exception. We are facing a huge problem as
> our code base is too cluttered with this kind of code:
> try{
> remoteProxy.callRemoteMethod();
> } catch (RemoteException e){
> }
> On Thu, Jun 11, 2015 at 10:52 AM, Dawid Loubser <dawid@travellinck.com>
> wrote:
>> 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

View raw message