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 <[email protected]> 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 <[email protected]>
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.
