ClientData problem

[lev grevnin]

My assignment states:
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.
Well, that means that this class (let's call it ClientData) will have to delegate to either the Data class for local mode, or for remote mode to RemoteData - a class which is sitting on the server side and accepts RMI method calls. Everything's clear, right? Not really! (at least for me).
This ClientData, when used in LOCAL mode will have to throw RemoteException for every method!!! That's stupid.. Of course i can do something like catching any exception thrown from the code of every method INSIDE the method, and then throwing an instance of a Runtime exception with appropriate message in it. This way nothing will have to be caught or declared. (don't know if it's a good idea or not). help, please

[Peter den Haan]

Originally posted by lev grevnin:
This ClientData, when used in LOCAL mode will have to throw RemoteException for every method!!! That's stupid..

Why? It's merely an expression of the fact that your ClientData may encapsulate a Remote implementation. This is the same as complaining that java.io.BufferedReader.close() still throws IOException when it's used to wrap a CharArrayReader. Of course it does. It's an expression of the fact that BufferedReader can wrap any kind of Reader, including the ones that can throw IOException in close(). If you just want a purely local implementation, you can use Data directly.

Of course i can do something like catching any exception thrown from the code of every method INSIDE the method, and then throwing an instance of a Runtime exception with appropriate message in it. This way nothing will have to be caught or declared.

But what's the point? You are just throwing away the benefit of checked exceptions and make exception handling more difficult. Not a good idea IMHO.
- Peter

[lev grevnin]

Peter,
in my previous thread "Data Client Constructors" you said:

My understanding is merely that you will have some client-side "Data-like object" in networked mode. (I suspect that Sun included this requirement to force your architecture into a certain direction; there have been a number of posts about this). This object will have constructors that are different from those of Data for the simple reason that the networked mode works completely differently.
My understanding is also that there is a requirement for this object to exist. That doesn't mean you have to write that class yourself; an rmic-generated class can well satisfy the requirement. I personally used RMI in my project, and had a server-side Remote class implementing the Data interface. The rmic-generated stub for this class satisfies the requirement quoted above in every respect.

VERY ORIGINAL SOLUTION! I'd never thought of that... This statement from a different thread actually answers better the problem i posed in this thread. Just use the RMI stub for remote mode and use the Data class directly for local mode, to put it simply, right??
thanks again,
-lev

[Peter den Haan]

Originally posted by lev grevnin:
VERY ORIGINAL SOLUTION!

I think it's far from original, although I must admit feeling rather chuffed when I first came up with it

Just use the RMI stub for remote mode and use the Data class directly for local mode, to put it simply, right??

That's exactly what I did. Code the client to access a DataInterface. Have exactly two implementations of this interface, one local (Data), one Remote. The simplest thing that could possibly work. The assessor was happy enough with it.
- Peter