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 catc
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
wrote:
> On 11/06/2015 16:24, Gr
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
Hi David:
Discussion below…
Cheers,
Greg Trasuk.
> On Jun 11, 2015, at 4:45 AM, Dawid Loubser wrote:
>
> I agree wholeheartedly with Palash Ray. The problem with this principle
> of "RemoteException" in River, which I have never agreed with, is twofold:
>
> * The most common and correct int
I agree wholeheartedly with Palash Ray. The problem with this principle
of "RemoteException" in River, which I have never agreed with, is twofold:
* The most common and correct interpretation of checked / unchecked
exceptions in Java, seen in the light of design-by-contract, is
o Unche
