Forums Register Login

Data Client Method Signature

+Pie Number of slices to send: Send
Hi all,
I have a simple design question to ask about the Method signature, expecially for the RemoteException part.
As I am planning to have one DataClient interface for both Local and Remote mode. So should I declare all the methods to throw java.io.IOException, as it is a superclass of RemoteException (to fulfil the RMI contract)?
I have read posts about changing the interface to throw java.lang.Exception. It just doesn't seem to be a good design choice, as the method signature sounds like "Use this method and expect that anything can happen". I just think it is not explicit enough.
And if I change my interface to throw IOException, is there any point to keep the custom made DatabaseException?
One of the disadvantage I can think of having throw IOException directly is that it will make the Data.java harder to change, just say that it will throw SQLException in the future....
Now I am struggling to see if I should use a more explicit Exception or a generic Exception (which makes it easier to change in the future). And is it possible to throw custom made exception?
Folks, pls comment on this one.
Thank you very much in advane.
+Pie Number of slices to send: Send
Well it is always a trade off. You would love to have more specific Exceptions, but then it leads to less flexibilty in future changes to classes that implement that interface. That is why I chose to throw Exception.
Mark
+Pie Number of slices to send: Send
Hi Trish,
I agree with Mark that it is a tradeoff. There are three kinds of exceptions involved: RemoteExceptions, IOExceptions, and DatabaseExceptions.
I found that that there is a semantic distinction between IOException and DatabaseException, although this distinction is not always so clear. IOExceptions say that something is wrong with the file itself, whereas DatabaseExceptions say that something is wrong with the record.
According to the instructions, you are free to modify the method signatures, since you may modify the Data.class. But I think it's also part of the test that you are show your ability to work with code that has been created by others (in this case some student), and that may have some flaws. This is why I did not change the signatures of the methods except adding RemoteExceptions.
+Pie Number of slices to send: Send
I've been struggling with this a bit too. I've had both my RMI implementation and local implementation implement FBNRemote which is my Remote Interface. The methods throw both RemoteException and DatabaseExceptions. But is this a good design since, the LocalImplementation should have nothing to do with RMI.
+Pie Number of slices to send: Send
Thank you very much for the comments.
I think I will also take the advice of adding this flexibility of my Data Client interface.
One more question, if I declare to throw Exception directly, should I also take the DatabaseException and IOException off the interface?
+Pie Number of slices to send: Send
Hi Pervez,
I posed myself the same question you have raised: When the app runs in local mode, it shouldn't declare any remote exceptions.
However, I found that the RemoteExceptions were less of a problem than code duplication. RemoteExceptions are not nice, but they don't harm, either.
Thus, my intermediary (the class between the GUI and Data) could be instantiated as a local object (simply by instantiating it with the new operator), or as a remote object (by getting a stub from a remote connection server).
Hope this helps.
If I had asked people what they wanted, they would have said faster horses - Ford. Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 563 times.
Similar Threads
Interface reuse
design issue: throwing generic exceptions? why?
NX: Remote/IOException in DBServices interface (Ken...?)
DBMain database interface & RemoteException
FBN : Exception in High level Data Interface
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 18, 2024 22:57:57.