Hi Peter, I've always been under the impression that Jini threw high level/general exceptions on purpose, specifically to counter this issue.
Presumable there is a small subset of exceptions (like RemoteException) which is going to exist on "all" JVMs, thus enabling compatibility across different versions. If I understand you correctly, you want to throw a more specific exception which some JVMs aren't going to have. Is that right? Would an acceptable solution be to introduce a new River exception which extends RemoteException. Then older JVMs can carry on catching RemoteException and dealing with it how every they see fit, and new ones can catch the more specific version. Personally, I think that throwing the general RemoteException (with a useful message) is the most appropriate thing to do at the 'River level'. An exceptions-dl.jar sounds a promising idea in any case. Does that make sense or have I missed something again? Cheers, Tom On Thu, Apr 29, 2010 at 11:13 AM, Peter Firmstone <[email protected]> wrote: > Perhaps an exceptions-dl.jar, which would only be required if an exception > was propagated from a jini 2.2.0 CDC node to a jini 2.1.2 or earlier java SE > node? > > Seems the least complicated solution? > > > Peter Firmstone wrote: > >> Got a tricky question about java.rmi.UnmarshalException and compatibility >> communicating with earlier versions of Jini. >> >> For Java CDC, I'm missing java.rmi.UnmarshalException >> >> UnmarshalException extends java.rmi.RemoteException, which I do have. >> >> UnmarshalException has no Serialized state, nor does it have any methods, >> only constructors. >> >> I can't go changing all existing public API methods that throw it, to >> throw say, net.jini.io.UnmarshalException since earlier platform versions >> won't have the required class file. >> >> I could throw RemoteException instead, however that might cause the >> Exception to be caught higher up the call stack. >> >> One solution seems to be to convert the serialized form to >> java.rmi.RemoteException, and then change it back somewhere, perhaps in JERI >> for java cdc? >> >> Any ideas? >> >> Cheers, >> >> Peter. >> >> >
