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 <paa...@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 <da...@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
>>
