What "parents" should I give to my implementation of RecordNotFoundException and DuplicateKeyException?
I'm thinking in IOException, is that ok?
Hum... let's think for a second. Is DuplicateKeyException an IOException? In other words, does the IS-A relationship apply here? If a record cannot be found, is it a problem regarding input/output?
Here's what I did: I created a DatabaseException, and had DuplicateKeyException and RecordNotFoundException extend it. I also had a few other exceptions to represent other situations, which also extended DatabaseException.
I agree, thanks for the suggestion!
But did your DatabaseException extend IOException or Exception?
I'm asking all of this, because my adapted interface to deal with the RMI RemoteException, throws RemoteException in its methods.
So I guess I would have to extend IOException in the 2 mandatory Exceptions, or in the DatabaseException in your example...
Is that correct?
Lucas cotta wrote:I'm asking all of this, because my adapted interface to deal with the RMI RemoteException, throws RemoteException in its methods.
I guess you are mixing two issues here. Ideally, there should be only one purpose to one exception(correct me if I'm wrong). RemoteException is meant for exceptions during RMI invocation. So, if you call a method, which throws RecordNotFoundException, then no matter if you call that method locally or remotely, it should throw only that exception (in case of exception of course).
You can further wrap that exception within RemoteException. Even better (which I did) - make your respective search method throw two exceptions - RemoteException and RecordNotFoundException.
What my point is - you can extend IOException for RecordNotFoundException, but RMI should not be reason for it. I simply extended Exception (super class of all exceptions) for those exception like RecordNotFoundException.
Thank you for the reply!
Yes I am indeed confused with the RMI implementation.
But ok, I've realized that the mandatory exceptions aren't related with the RemoteException.
I'll change my question entirely:
From what I've searched, I understand that to implement a interface that extends Remote and DBMain, the methods called remotely must throw RemoteException.
But DBMain don't throw it in its methods. So I need to create an adapter that "translates" the DBMain with RemoteException in the methods.
In my controller class I have two situations, the standalone mode where I can use the original DBMain, and the network client mode that will use the AdaptedDBMain interface.
Should I create 2 instance variables, one for DBMain and another for AdaptedDBMain, and use them accordingly with the current running mode? Or maybe use just AdaptedDBMain, since in the end it will use the original Data class (but then the DBMain won't be used)?
My DatabaseException extended Exception. A possible design of the business layer can be found here.
Now, for the other stuff, I don't know if you already saw this, but here is a paper I wrote about how to approach this certification and how to design the code. I think it may help you clearing your doubts!
That's bad design! And will result in a lot of ugly (and unnecessary) code (lots of ifs to see which instance variable you need to use). Both standalone mode and network mode should use the same interface.
I introduced a business service layer with just 2 methods (book & find). These methods could throw some business exceptions (room not found, room already booked,...) and also the RemoteException. This interface will have 2 implementations (1 for standalone, 1 for network) and both will use the Data class as an instance member (to invoke methods on). So you just need to develop 1 client and based on the startup parameter you'll use the appropriate (standalone or network) implementation to call methods on. That's a thin client approach (all logic happens on the server).
If you prefer a thick (fat) client approach you can do something similar, but your business service layer will contain similar methods than DBMain interface, but slightly adapted (throwing RemoteException, maybe using a POJO instead of String,...). The rest will be the same as the thin client approach.
So you'll end up with a nice design and don't have unnecessary, ugly code.
Hope it helps!
 seems the great and wise Roberto was 15min faster, but both responses lead to similar results (that's because great minds think alike )