Hello everyone, From what I've read from many posts, I see that many people have: - a DataInterface which extends java.rmi.Remote and has all public methods from the Data class throwing generic Exceptions (either IOException or Exception). - a RemoteData class which extends UnicastRemoteObject and implements DataInterface. This class delegates most of its methods to Data. Its methods throw RemoteException. My design was very much like Andrew Collins's in his post "Local mode - Remote mode", except for the name of the classes which were different. Mark's comments about Andrew's design: "Serverside is breaking all the OOP rules." made me reconsider my design. But I still don't understand why I should have different classes that do the same thing just because one throws RemoteException and the other doesn't. Unless I code twice the same thing on the client (one handling the RemoteException, the other handling a generic exception which may never occur, by the way), I don't see why I should make the distinction between RemoteException in a RemoteData class or a generic exception in the Data class. I really respect everyone's opinion and I am concerned about my design, but I can't change it if I don't agree with the changes. Please, someone, convince me!
My DataInterface methods throw both RemoteException and DatabaseException. In RemoteData class I store any generic exception caught by the server inside the new RemoteException object. Look at the constructor for RemoteException. It can take another Throwable object.
Hi Leonardo, i have got a DataAccess interface that declares the methods of the Data class (and throws exception for every method). the data class implements this interface. I also have a RemoteDataAccess interface which is a sub interface of DataAccess, and this throws remote off each method. becasue the RemoteExcetpion is a subclass of Exception this is fine. At the GUI level I am only working with the DataAccess interface, so basically everything is written to catch excpetions, and report a generic error message to the user. the user would not want to know the technicalities of the exception casue. these should be logged for the systems adminstrator to see. i dont knoew if that is riht or wrong - i am still working on the assigmnent - and it seems like it's never going to end cheers, dean
The main reason I choose to throw generic exceptions in my interface was to be able to reuse it in both Remote and Local modes. My Data class doesn't implement the interface, therefore never becoming a remote object, however the remote and local implementations do. By throwing generic errors in the interface I allow for the implementations to decide which specific errors they want to catch and throw.
Joined: Feb 15, 2002
I understand everyone has their own way of thinking and therefore each one of us has their own design. What I don't understand is: let's take for instance the getRecordCount() method. From the Data class we know that it doesn't really throw any exception. The only reason it should throw an exception is when it is executed from a remote object. Why then should we declare it (or any method that delegates to it) to throw a generic exception when, in fact the only exception that might ever be thrown is a RemoteException? I mean, it doesn't matter whether we're in local mode or remote mode, the client we'll always have to catch an exception - even though in local mode it will never be thrown. I'm not saying that throwing a generic exception is bad and that throwing a remote exception is good or the other way around. I just don't know what difference it makes. yo! Leo
Joined: May 15, 2001
For me it was a case of redundency. A method of defining the public methods of Data class is needed for the client. I chose to use an interface I didn't want to use two one local and one remote, so I throw generic exceptions and define them in the implementation type. I didn't want one interface for local and another for remote when they contain the same public methods. One point to make here is that in local mode my implemantation still wraps calls to the Data call. I didn't want to be too dependant on that class remaining "as is". Hence the abstraction.