Hi everyone, I'm trying to justify the use of a single data interface in my design document. In my view the DataAccess interface provides the client access to the database (API), whilst hiding the actual implementation i.e local or remote from the client. If this is true, then client must therefore catch both DatabaseExceptions and RemoteExceptions. The implication of this is that the DataAccessLocal implementation must delcare that it throws RemoteException as it extends remote, whilst never actually throwing the exception. I would argue that if a client only required local mode that it could us the Data class. Any comments? Thanks Jason.
If this is true, then client must therefore catch both DatabaseExceptions and RemoteExceptions.
Actual in my DataAccessFacade, which the client uses. I catch the DatabaseException, then I also catch Exception, in the catch of the Exception, I create a new DatabaseException, put a nice message in it and then throw the DatabaseException. This way the client only has to catch the DatabaseException.
Also why not just have your DataAccess interface throw Exception? It is generic and allows you to throw the more appropriate exceptions in the implementation class. Mark
Hi Mark, I'm in two minds about the interface throwing Exception, whilst it provides flexibility for future implementations to throw exceptions derived from Exception, it means that the client class must catch Exception. This in my experience is a bad thing as you may catch exceptions which should propagated higher up the application. Thanks for you're input Jason.
The implication of this is that the DataAccessLocal implementation must delcare that it throws RemoteException as it extends remote, whilst never actually throwing the exception. Not true. The implementation class need not declare any exceptions. But any remote interface it implements will need to declare throws RemoteException for all methods, and the rmic-generated stub class will have methods that really can throw those exceptions. But
Here Data implements two interfaces, identical to each other except that one is remote and the other isn't. You can use Data locally and refer to it using the DB interface, or you can use it in network mode and refer to it with the RemoteDB interface. The main problem I see with this is that it may not have sufficient separation between the networked code from the non-networked code, as required in the instructions. When in local mode we're still instantiating a class that extends UnicastRemoteObject, even though it never gets used as a remote object. So that's a bit weird, but I think it may be acceptable. Personally I'd rather have separate classes to handle the network connection, but this is an option at least.