Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
MIME-Version: 1.0
In-Reply-To: <5579A0A2.7080901@travellinck.com>
References: 
 <CA+BHFodJcDFgY+W-RCfX5VRmp=ZN0wZY0dPb2LSFCVTUdSBodw@mail.gmail.com>
	<B85ABC94-A1BE-40DD-9206-5C12B8590FA8@stratuscom.com>
	<55794A90.7080907@travellinck.com>
	<94AE2142-7EB0-4AF3-88FA-BFB3023CC3B5@stratuscom.com>
	<5579A0A2.7080901@travellinck.com>
Date: Thu, 11 Jun 2015 23:29:53 -0400
Message-ID: 
 <CA+BHFocT7mb723rfs5=3DTCM3E5wU=Bnmfx+ZgZ3DeCnXp0R3w@mail.gmail.com>
Subject: Re: Using an unchecked exception instead of RemoteException
From: Palash Ray <paawak@gmail.com>
To: dev@river.apache.org
Content-Type: multipart/alternative; boundary=047d7b62499cb160b5051849b84b

--047d7b62499cb160b5051849b84b
Content-Type: text/plain; charset=UTF-8

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
>

--047d7b62499cb160b5051849b84b--