wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Interface to Data Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Interface to Data" Watch "Interface to Data" New topic
Author

Interface to Data

Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Hi everyone
It seems that most people have taken the route of having Data implement a DataInterface and then to have a RemoteData class that implements a RemoteDataInterface that is effectively DataInterface but which extends Remote.
I have been struggling with exception handling for some time now with regard to handling exceptions that need to be thrown in remote mode and not in local mode and how the client should handle it.
I have tried several different designs but am still not happy so was wondering what objections there might be to still having two DataInterfaces - one local and one remote - but have the remote one NOT extend DataInterface but still declare all the same methods only throwing RemoteException in addition to DatabaseException.
My design is such that I have a model that makes calls to either a LocalConnection object or a RemoteConnection object (RemoteConnection object is not a Remote object it just has a reference to a RemoteData which is a Remote object.)
In my LocalConnection I would like to just be able to catch DatabaseException and in my RemoteConnection I would like to catch DatabaseException and RemoteException. If I separate the two interfaces I can achieve this nicely and in fact in my design I don't require the two DataInterface objects (local and remote) to implement the exact same interface as all the client program cares about is interacting with the Connection object which has methods search() and modify() and throws uniform exceptions. I might even leave out lock() and unlock() from the local interface as I think locking is not required in this mode.
Apart from the fact that having two interfaces with the same methods (or most of the same methods) but different exceptions is probably not ideal I can't see anything else against this. I still have two interfaces I am just giving them license to vary - all that matters is the connection object can provide all the same services in both modes.
If anyone can point out any errors in my thinking here I'd really appreciate it.
Many, many thanks Sam
Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Please any opinions on this would really be appreciated as I haven't heard of anyone doing this as yet and wondered why.
Thanks again Sam
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
You have two exception types, DatabaseException and RemoteException. Could you make those two types extend (subclass) another type of Exception? Look at the Exception hierachy in the RMI API.
When you have found that supertype, can it be validly be used in RMI code and non-remote code in place of RemoteException/DatabaseException?
Just trying to burn up some brain energy...
[ April 25, 2003: Message edited by: Barry Gaunt ]

Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Jeff Wisard
Ranch Hand

Joined: Jan 07, 2002
Posts: 89
Barry,
You've made mention of the RMI exception hierarchy before and so I assume you mean the rmic compiler won't complain if your remote methods throw IOExceptions instead of RemoteExceptions. However, with the Contractors project, we have been given a specific interface (DBAccess) that we cannot modify.
Here is the interface:

The RecordNotFoundException and DuplicateKeyException are exceptions that we are required to create. These could extend RemoteException and that would be fine. However, note the findByCriteria() method. It throws no exception at all. Also, the unlock() method throws a SecurityException, which does not extend IOException. So, this interface becomes difficult to turn into a Remote interface because not all of the public methods can throw IOException....and we are not allowed to add RemoteException to them.
So, several of us are still looking for a nice way around this problem. I may have an idea, but am not ready to post yet.


Jeff Wisard<br />Sun Certified Java Programmer (Java 2)<br />Sun Certified Web Component Developer
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
Yes, Jeff, I have the same interface. The IOException idea is more for the implementation of the Adapter pattern which is going to adapt the given interface to the client's needs.
As Shalloway and Trott say in their book "Design Patterns Explained":
this is saying that we need a way to create a new interface for an object that does the right stuff but has the wrong interface.
-Barry
[ April 27, 2003: Message edited by: Barry Gaunt ]
Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Hi Barry and Jeff!
Sorry for late reply, haven't been able to log on since before the weekend. Barry thanks so much for that. I had been staring at it so long it never even occurred to me to have Database exception extend IOException - now I feel very dim

but glad I asked the question

Many thanks Sam
shan chen
Ranch Hand

Joined: Apr 09, 2003
Posts: 70
I tried extending DatabaseException from IOException or RemoteException, no of them work.
I guess Factory Pattern is impossible for this assignemet. With Adapter pattern, RMI can work.
My question: is it important to have Factroy pattern?
thanks.
Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Shan
If you want your local and remote databases to implement the same interface and DatabaseException is made to extend IOException and RemoteException already extends IOException then you have your answer.
The fact that in remote mode your Data object will throw both Database and RemoteExceptions and in local mode it will only throw DatabaseExceptions doesn't change the fact that both modes are only throwing a type of IOException.
Now if you use an Adapter pattern and have a factory that creates either local or remote adpater instances according to the type of connection mode then you are perfectly set up to process the actual exceptions thrown in the way appropriate by the type of database you are connected to.
For instance your LocalAdapter might chose to just catch IOException. This will enable it to catch all exception types thrown by the DataInterface and to process them as DatabaseExceptions as we know that in local mode no RemoteExceptions will actually be thrown. In the RemnoteAdapter we might chose to distinguish between Remote and DatabaseExceptions and process them differently.
So yes it is possible to use the Factory pattern, you can use the Adapter pattern to translate the actual exceptions thrown into something that your program can understand and having all exceptions inherit from the same parent class enables Data to implement the same interface in different modes.
Hope that helps
Sam
shan chen
Ranch Hand

Joined: Apr 09, 2003
Posts: 70
Hi, Samantha,
Thanks for your suggestion. I actually have worked it out, keeping both Factory and Adapter pattern. My schema is close to Jeff Wisard's idea with some differences:
http://www.coderanch.com/t/183273/java-developer-SCJD/certification/NX-Contractors-Interfaces-design


If you want your local and remote databases to implement the same interface and DatabaseException is made to extend IOException and RemoteException already extends IOException then you have your answer.

Does this mean we need a new interface, which have the same method as DBMain/DBAccess, but throws IOException?

If this is true, then your idea is similar with Ta Ri's idea, in the same link mentioned above.
I think both works.
shan
Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Hi Shan
I don't know the contents of DBAccess or DBMain as I doing the older exam but what I meant was that if your local database throws DatabaseExceptions for example and your remote database needs to throw DatabaseExceptions AND RemoteExceptions then how do you provide an interface that they both implement and at the same time enable yourself to handle one type of exceptions in local mode and another kind in remote mode?
The simplest way is to make all exceptions thrown inherit from the same parent class then you can throw the parent class exception in your interface (and any subclass exceptions if you like.) This means that in your code you can chose to catch just the parent class (say in local mode) or you could chose to catch any of the subclass exceptions plus the parent class exception (say in remote mode.)
The Adapter pattern allows you to process the same interface exceptions differently and you don't need to duplicate any code as you can have your local and remote adapters inherit from an abstract class that does most of the leg work except for exception handling.
Sam
 
GeeCON Prague 2014
 
subject: Interface to Data