river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Palash Ray <paa...@gmail.com>
Subject Re: Using an unchecked exception instead of RemoteException
Date Fri, 12 Jun 2015 03:34:33 GMT
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){
  throw  new RuntimeException(e);
}

Instead of that, I would like not to have to catch these exceptions. There
is a whole debate in our organisation, and we are seriously considering
moving over to Spring Remoting, which, does not mandate these ugly checked
exception:

http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html

In my 2 years of using Jini, one feedback that I have as a developer is its
overtly complex. For instance, if I want to configure security, its so
complex, that I have to spend days together to get it up.

I strongly believe that we should try to make things simple for the users.
And flexible.

Thanks,
Palash.


On Thu, Jun 11, 2015 at 11: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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message