river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: River exception usage.
Date Thu, 04 Oct 2012 14:35:49 GMT
Of course, there is always the whole business of whether a "RemoteException" 
implies a completed, partially completed, or never-started operation.   The 
answer, of course, is "it depends".   The reality is that transactional 
behaviors need to be part of what you are doing, if you have any hope of dealing 
"effectively" with "RemoteException" for any type of 
"modification/with-sideeffects" remote call.  More specialized RemoteException 
types, could help spell out the details for specific types of 
"transports/endpoints", but I'm not sure there is really any value in that.

I, long ago, switched to using "throws IOException" on my remote interfaces, 
because I wanted to be able to deal with running those interfaces across other 
"technologies" where IOException would happen and RemoteException would not.

Gregg

On 10/4/2012 2:12 AM, Dan Creswell wrote:
> One other thing that just sprang to mind:
>
> Exceptions thrown via the service API can come from within the proxy itself
> or have been "forwarded" from the remote back-end as the result of
> server-side issues. I'm not sure we'd need to differentiate in terms of
> groupings/classes of exceptions but as we're thinking about all this, worth
> mentioning.
>
> On 3 October 2012 21:54, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>
>> Hi Greg,
>>
>> I tend to agree. I've gotten to the point to declare IOException as well. I
>> think it defines the semantic correctly, in that the interface to the
>> network is by definition I/O. As long as the method declares either
>> IOException (or subclasses of it like RemoteException) I'm fine either way.
>>
>> Only thing to keep in mind is that the service should not be throwing an
>> IOException (or RemoteException) if an application error occurs. For
>> application errors (exceptions), we should advise that application specific
>> checked exceptions be raised with appropriate causes. If the cause itself
>> is either not serializable or not loadable by a client, care needs to be
>> taken to extract the cause's StackTraceElement(s) as the cause.
>>
>> HTH
>>
>> Dennis
>>
>> On Wed, Oct 3, 2012 at 4:03 PM, Greg Trasuk <trasukg@stratuscom.com>
>> wrote:
>>
>>> I'm curious if anyone else has an opinion on something:  Gregg
>>> recommends below that methods on remotely-accessible API should be
>>> declared to throw 'RemoteException'.  I agree in principle, but a long
>>> time ago I convinced myself that 'RemoteException' was specific to the
>>> RMI technology, which is not actually required in Jini (The end of
>>> protocols, etc).  If I had a service provide a smart proxy that talked
>>> to a machine using a serial port, was it still correct to have the API
>>> throw a RemoteException?  It didn't seem right to me.
>>>
>>> So... I got in the habit of declaring service api methods to throw
>>> 'IOException' rather than 'RemoteException'.  IOException is actually a
>>> superclass of RemoteException, so if you happen to implement a service
>>> using RMI or JERI, the proxy is still compatible, but the api is then
>>> still consistent with the idea that there might be a problem with
>>> input/output (hence we're not hiding the fact that failure is possible,
>>> we're just stating it in a generic way).
>>>
>>> Is that sensible, and should we recommend it, or is it just splitting
>>> hairs and shaving yaks?
>>>
>>> Cheers,
>>>
>>> Greg.
>>>
>>> On Wed, 2012-10-03 at 15:08, Gregg Wonderly wrote:
>>>> Any remote, catchable exceptions should be "RemoteException"
>> subclasses,
>>> and where applicable, they should be subclasses with viable names.
>>>   Anything that comes from the APIs of River, just needs to be
>> specifically
>>> about the type of issue.  I, personally, only wrap things in
>>> "RuntimeException" when I need to change the visibility, from an API
>>> perspective, of where something is caught and handled, vs having to
>> expose
>>> some logic to another package which involves an exception it doesn't care
>>> about.
>>>
>>>


Mime
View raw message