Sim IJskes - QCG wrote:
On 06/14/2010 07:18 AM, Peter Firmstone wrote:
I've been having some thoughts about what Chris said about using
IOException where possible for clients using non remote classes and
interfaces, instead of RemoteException.
Nope, only ever loaded locally. The API in question, doesn't extend
remote, I just thought it made more sense to declare it throws an
IoException, even if the implementation throws a RemoteException.
In fact many API methods throw a RemoteException because their
implementation use java.rmi.Remote. If an implementation was to use
some other method of network communication or language, then the
IOException might make more sense. RemoteException extends IOException,
so new clients would still catch the RemoteException since it's a
subclass.
Eventually at some later date in the future (say 5years) another
implementation would have the freedom to throw an IOException instead.
Just thought it would be better if over time the API in River that
doesn't include java.rmi.Remote in it's interface declare it throw a
more appropriate Exception.
Won't break anything if the implementation doesn't change, not a biggie
if we don't do it either.
Just a thought.
Peter.
It still would not work would it? Will a java.rmi.* package ever be
downloaded from a non-local codebase (loaded through other than system
classloader)?
Gr. Sim
