Checked exceptions design question

Question

Hi,
I'm writing an RMI replacement which has similar semantics and I have the following design problem:
- A client invokes server.method(myList)- myList is of type List and is actually a Remote object which resides on the client code. So when the server method uses this list, it is actually communicating back with the client and sending resulting back and forth.
- The server code is defined as
public Server
  public void method(List myList)
    // A network error occurs while trying to access myList
}Ideally I'd like to throw RemoteException from the list in case of a network error, but I can't do that because RemoteException is a checked exception and cannot be added to the List interface (it would break its contract). So I was thinking maybe that the list should throw a custom Error if an I/O occurs and then my framework would catch it at the end of the method and throw RemoteException back on the client-end of things. I am uncomfortable throwing and catching an Error but I don't want the server-code to try to catch the thrown exception either. As far as I can tell, if a RemoteException occurs from inside the list, there is absolutely no way for the server code to recover. It can't request a new method argument from the client and therefore it must always simply rethrow the exception. What do you think? Do you have a better idea?
Thanks,
Gili

Answer 1

The term client and server is relative. Whoever is hosting the remove object I consider to be the server for that object. So if the client exports an object and sends it to the server, then in this case, the client is the host or "server" for that object.
So in this case the receiver of the object is the one that has to deal with the exception. However, the receiver can pass the exception back to the caller if it chooses. I don't see any reason for your "server" to fail because it could not successfully invoke a method on an object from your "client." If your client requests the server to do something, and the server could not, the server just tosses an exception back to the client. I may be missing your problem!?
For hibernate, handling hibernate failures is a bit different from handling remote failures. In either case, I let the client deal with it. My remote interfaces look like so
public interface INamedObject extends Remote {
     public String getName() throws RemoteException;
     public DSID getIdentifier() throws RemoteException;
     public void setName(String name) throws  RemoteException, ServerException;
    public Set<? extends IPropertyType> getPropertyKeys() throws  RemoteException, ServerException ;
    public Map<? extends IPropertyType,? extends String> getProperties() throws  RemoteException, ServerException ;
    public String getProperty(IPropertyType key) throws  RemoteException, ServerException ;
    public String setProperty(IPropertyType key, String value) throws  RemoteException, ServerException;
    public String removeProperty(IPropertyType key) throws  RemoteException, ServerException ;
}The methods that do not require any hibernate activity generally just throw RemoteExceptions. However, the ones that do hibernate stuff also throw ServerException which is my own custom exception. Its just a serializable class. When the client gets a ServerException it knows that its not a connection problem, but a problem with the server itself. Such as the db crashed or some other thing.
Note that my objects have identifiers. So if you make a call on a remote object, and it fails, you reestablish the connection to the server, then re-request that remote object using the identifier, then try the request on it again. For distributed computing you need to be able to handle this IMHO.