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. > > > > > > > > > >
