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