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