Exception stratigy in scjd???

[walid aly]

Dear All
I am having a problem in how to handle exceptions,since we have the same class that will do local and remote shall i handle like this:-
class searchcommand{
try{
search()}
catch(RemoteException r){}
catch(DataBaseException ){}
}
in this case i will have to declare all the methods in the abstract adapter to throw remote and i will force every one even if he want to implement the methods in local mode to handle remote exception although it will neve be thrown
WHAT SHALL I DO?
walid

[Sure Vat]

I think it is a design issue. You could easily get rid of this problem by having two classes, one for remote and other for local, derived from an abstract base class. Then for catching the exception from both cases, you could define a user defined exception, which will be thrown in both cases.
I am sure what i have specified here is a broad idea rather than a precise one to the point. But i hope you got the point.

[walid aly]

well
there is implementation problem in what u said
i do have the design u pointed BUT
in the class which actually calls a method using a method in any of the local or remote adapters we r using a refrence of type abstractadapter
some methods in the local adapter throw nothing , but all the methods in the remote adapter throws remote exception, so we we just put try cath around all the methods (working with myexceptiobn), in this case all the method in the abstract data will have ....throes myexception
???
thanks
walid

[Max Habibi]

Hi walid,
There are a couple of approaches here. One of my favorites is to provide custom gui exceptions to the front end, even as back end exceptions get logged. What does that mean?
Say the back end throws a RemoteException. Catch that in your adapter and log it(or just print it to the screen: logging it to a file introduces the additional risk that your fileio will fail).
Now, the adapter, in turn throws a customer exception, say ClientNotFoundException, to the gui client. The gui client displays that user friendly message, and goes on from there.
This sort of thing is particularly easy if you use jdk 1.4, because it offers exception chaining.
make sense?
all best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[walid aly]

i understand what u mean BUT
1-i will catch remote and throw myownexceptin
so the final handling will be left to the final method in gui
so now this method will always has to handle the exception formed by the remote process although some times it will work in local mode
is this an overhead ? ???
2- do u also mean that in local adapter i will catch whateveexception and also throw my own wxeception
3-of course u know i will have to add throws myownexception to the signature of the method in the absract adapter so that the compiler will not complain (as i am using a refernce of type abstarct adapter to invoke the methods?

thanka alot
walid

[Max Habibi]

The GUI simply works with an connection object. Connection, in turn, is implemented by RemoteConnection and LocalConnection. Now, both RemoteConnection and LocalConnection throw, say, a "DBConnectionFailedException", and the GUI knows what do with that. However, the difference is that the LocalConnection throws it because it couldn't find the file locally( thus, it caught an IOException, logged it, and then threw a DBConnectionFailedException), where the RemoteConnection throws it because it caught a RemoteException(which it also caught an logged). For the moment, ignore the fact the a RemoteException is a IOException.
Of course, this is simply one design. However, it does keep the GUI itself from knowing( or caring) that it's talking to a remote client.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 26, 2003: Message edited by: Max Habibi ]

[walid aly]

cool
but what about the methods in class data that throw nothing like get datainfo() , should i make its equivelent in localadapter throws myexception???(although it will never actually throw)
Thanks alot
Walid

[Max Habibi]

That's a interesting question. One answer is, of course, yes. Another is to tier your application still more, thus, for example, having LocalConnection really be a service provides who has a RemoteData object as a member variable. Either way, if the remote Data object throws an exception, then you should log it, and throw, say, a FatalGUIException.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[walid aly]

"LocalConnection really be a service provides who has a RemoteData object as a member variable"
can u plz clarify?

[Sam O'Neill]

Max I think I'm missing something here because you wrote that

the difference is that the LocalConnection throws it because it couldn't find the file locally( thus, it caught an IOException, logged it, and then threw a DBConnectionFailedException), where the RemoteConnection throws it because it caught a RemoteException(which it also caught an logged). For the moment, ignore the fact the a RemoteException is a IOException

but how is the RemoteConnection able to catch the
RemoteException if it is itself a Remote object?
To clarify I have a RemoteConnection object that contains a reference to a Data Object and a LockManager object and it exposes all the same method calls of Data plus criteriaFind(). RemoteConnection implements the RemoteConnectionInterface which extends DataInterface. DataInterface declares all the methods of the Data class and each method in this interface throws RemoteException.
The RemoteConnection object routes calls to its methods to either the contained Data or LockManager instance which do not throw RemoteExceptions so how are you managing to catch the RemoteException thrown by the stub of the RemoteConnection object within the RemoteConnection object itself?
I hope that made at least some sense!!!
Thanks Sam

[Max Habibi]

Think of it this way. You have a RemoteData object, who provides access to all of the methods of the Data class: Fine and good.
Now, you have a RemoteConnector, who has a RemoteData class as private member variable. RemoteConnector( in this design)is not a RemoteObject: he just has access to one. This RemoteConnector class offers only a few methods: search and modify. Both of these use the internal RemoteData class, and they both throw various GUIExceptions. Thus, while Search might catch various exceptions from RemoteData, it simply logs those exceptions, and throws a 'dumb' exception for the sake of the GUI: Say, a "SearchFailedAndYouAreUglyException". The GUI then does the appropriate thing with that exception.
The GUI doesn't know, or care, if it's really using a RemoteConnector and/or a LocalConnector. They both implement the Connector interface, and thus the GUI simply uses that interface to point it's connector. So how did the GUI get the appropriate connector in the first place? It asked a factory to provide a connector to it, which factory did so.
The LocalConnector works the same way: however, he simply has a Data object as a member variable.
make sense?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[walid aly]

some of the methods in class data does not throw at all any exception
y should i catch gui exception when i am doing it local??
walid

[Max Habibi]

Not sure I understand your question. can you be more specific? Remember,the GUI doesn't have direct access to Data in this case: only to the Connection. When the Gui wants to do something, it asks Connection to take care of that something for it. Thus, Connection might offer a reserve() method, which is called by the GUI. Inside Connection.reserve, you might see

myData.lock(recno);
...
myData.unlock(recno);

HTH,
M

[Sam O'Neill]

Okay I understand - you are wrapping it one more time within a local object that catches the exceptions and then throws its own kind to the GUI.
Can I also ask a question about logging Max. When you say "log to the screen" to avoid fileio blocking, do you mean to add the message to the actual error message displayed on screen or to log it to System.err? I am not using the Logger facility but do feel my aplication lacks the means of separating the chained error messages that would not be very user friendly, but must be reported if a problem is to be resolved, and the a user tailored messages.
Many thanks Sam

[Max Habibi]

Originally posted by Sam O'Neill:
Okay I understand - you are wrapping it one more time within a local object that catches the exceptions and then throws its own kind to the GUI.

Exactly. Connector is an adapter.

Can I also ask a question about logging Max. When you say "log to the screen" to avoid fileio blocking, do you mean to add the message to the actual error message displayed on screen or to log it to System.err? I am not using the Logger facility but do feel my aplication lacks the means of separating the chained error messages that would not be very user friendly, but must be reported if a problem is to be resolved, and the a user tailored messages.
Many thanks Sam

Yes, I meant System.err for exceptions. And you might want to consider the logger facility, just because
1. it's easier
2. This is as good a time as any to learn how to use it.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Originally posted by Saraswathy Krishnamoorth:
Mark:
The GUI doesn't know, or care, if it's really using a RemoteConnector and/or a LocalConnector. They both implement the Connector interface, and thus the GUI simply uses that interface to point it's connector. So how did the GUI get the appropriate connector in the first place? It asked a factory to provide a connector to it, which factory did so.
Network Mode:
I have a ConnectionFactory interface which implements remote and has getConnection method. The connectionFactoryImpl class implements connectionFactory interface. I lookup for the connectionFactoryImpl class and use its getConnection method. It returns a unique connectionObject which had remoteData memeber variable.
Local Mode:
I simply create an instance of LocalConnection object which has Data member variable. I am not using any factory.
Can u explain about what u mean by GUI asked a factory to provide the connector. Do u mean that there should be another factory in addition to connectionFactoryImpl class.

Well, I'm not saying there should one or the other: that' up to you . However, I would probably have the ConnectionFactory return a connection reference. That connection reference would point to either a RemoteConnection or a LocalConnection.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Saraswathy,
I don't think we're communicating as well as possible. Do you have a specific question?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 28, 2003: Message edited by: Max Habibi ]

[Saraswathy Krishnamoorth]

Hi Max,
Sorry for not being specific.
In network mode:
I have a RemoteDataFactoryImpl which is bound to Registry. It's getConnection method will return a unique Remote Data object. I use a remoteDataWrapper around the remoteData object. This wrapper has methods like BookFlight, SerachFlights etc.
In Local Mode:
In local mode I have a LocalDataWrapper around the Data object. This wrapper has methods like Book Flight, SearchFlights etc.
I wanted to know whether this approach is corrrect.

[Max Habibi]

Originally posted by Saraswathy Krishnamoorth:
Hi Max,
Sorry for not being specific.
In network mode:
I have a RemoteDataFactoryImpl which is bound to Registry. It's getConnection method will return a unique Remote Data object. I use a remoteDataWrapper around the remoteData object. This wrapper has methods like BookFlight, SerachFlights etc.
In Local Mode:
In local mode I have a LocalDataWrapper around the Data object. This wrapper has methods like Book Flight, SearchFlights etc.
I wanted to know whether this approach is corrrect.

Ok, I think I'm starting to see where you're coming from. Yes, I think you're approach is pretty much what I'm describing. You're simply using the term RemoteDataWrapper where I'm using the term RemoteConnector.
However, you might want to consider the following, if you haven't already. Have RemoteDataWrapper and LocalDataWrapper implement the same interface, say DataWrapper. DataWrapper should provide the signatures for BookFlight, SearchFlights etc, and throw the appropriate GUI exceptions. RemoteDataWrapper and LocalDataWrapper should implement these signatures. If there are exceptions that are thrown by Data(or RemoteData), those should be logged by DataWrapper, and business friendly exception should be thrown from DataWrapper to the GUI layer.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
Make sense?

[walid aly]

Dear Max
i will try to make my self clear
i have a localwraper class and a remotr wrapper class both deals with the same methods in class data .
in remote mode :the server catch all the databaseexception ,ioexception and throws remote exception wrapped around the real exception
.......................................
in localwraper :the methods that throw databse or ioexception catch them and throw myownexception.
...............................
the remotewrapper catch remoteexception(which might also be a remote exception wrapped around io or database) and throws myownexception.
.....................................
now the PROBLEM
some method in the class localwrapper does not throw anything
now in the gui (last class to deal) should i enclose all the methods in try-catch my own exception, if i do thios i will have to declare all methods in localwraper to throw myownexception (which i feel is not correct to do)
plz advise

[Max Habibi]

Originally posted by walid aly:
now the PROBLEM
some method in the class localwrapper does not throw anything
now in the gui (last class to deal) should i enclose all the methods in try-catch my own exception, if i do thios i will have to declare all methods in localwraper to throw myownexception (which i feel is not correct to do)
plz advise

Ok, I think I'm with you now: no, I don't think you should.
All best,
M

[walid aly]

now i a m a bit lost
what exactly should i do ???
walid

[Max Habibi]

Maybe we should speak in terns of specifics. Which methods, exactly, are yu talking about?
M

[walid aly]

public int getRecordCount() { return recordCount; }
how would u deal with it?
thanks..........

[Max Habibi]

You have two basic paths here. The first is to provide a proxy to the GUI, which offers a limited set of functionality( like search, reserve, releaseReservation, etc.). Don't offer access to methods that aren't needed by the GUI(say Add, remove, etc.,), since they are not used. In this scenario, the exception handling becomes pretty easy, because only exposed methods throw YourOwnException.
The second path, if you decide to give the GUI access to all of the methods of Data, is to do exactly what you said, and surround all of your calls with try/ catch statements.
Make sense?
M

[Saraswathy Krishnamoorth]

Instructions state that
"To connect with your server,you should create a client program. This implementation should inlcude a class that implements the same public methods as the suncertify.db.Data class."
If the GUI proxy is the Dataclient then it should expose all the public methods of Data according to the instruction. If GUI proxy is not the DataClient then which one acts as DataClient.

[Max Habibi]

Originally posted by Saraswathy Krishnamoorth:
Instructions state that
"To connect with your server,you should create a client program. This implementation should inlcude a class that implements the same public methods as the suncertify.db.Data class."
If the GUI proxy is the Dataclient then it should expose all the public methods of Data according to the instruction. If GUI proxy is not the DataClient then which one acts as DataClient.

The class that offers the Data interfaces, in the design I'm suggesting, is RemoteData. RemoteData is not accessed directly by the GUI: it is accessed indirectly through connection Proxy. Thus, all remoteException are caught and logged by the Connection Object.
Make sense?
M

[Burk Hufnagel]

Max,
Pardon my jumping in but I'm currently in the middle of deciding how to handle the RemoteExceptions introduced by RMI so I've been following along.
I'm curious, where would you log the errors on the client side? If you write them to a file then who reads it and what happens if there's file io errors? If you store them in memory then you'll need to display them somewhere - like an error log window.
The only other place I can think of logging the error is on the server via RMI - which could set off a whole new round of error logging.
None of the three seems appropriate to me, though I hate the idea of dumping the information in a bit bucket and just displaying a generic "Communications error" message.
If you've got a good place to log the info to, please tell me.
Thanks!
Burk
... and now back to the message thread already in progress.

[Max Habibi]

Originally posted by Burk Hufnagel:
Max,
Pardon my jumping in but I'm currently in the middle of deciding how to handle the RemoteExceptions introduced by RMI so I've been following along.
I'm curious, where would you log the errors on the client side? If you write them to a file then who reads it and what happens if there's file io errors? If you store them in memory then you'll need to display them somewhere - like an error log window.
The only other place I can think of logging the error is on the server via RMI - which could set off a whole new round of error logging.
None of the three seems appropriate to me, though I hate the idea of dumping the information in a bit bucket and just displaying a generic "Communications error" message.
If you've got a good place to log the info to, please tell me.
Thanks!
Burk
... and now back to the message thread already in progress.

Hi Burk,
I assume that you're talking about application errors that happen client-side, instead of the normal usage messages like "no search criteria entered" or "unable to lock record" that might pop up in a dialog.
I suggest that you log the gui application errots to the standard err. That way, you're avoiding potential IO issues, but still supplying detailed information. If you like, you can use a logger specifically for the client side, and another for the server side. Thar way, you can brag that it would be easy to provide a custom handler, per logger, that output to a file, if you ever needed one.
HTH,
M

[Saraswathy Krishnamoorth]

Thanks Max. Now it is clear for me.

[Max Habibi]

Happy to help, hope it works out .
M

[Sam O'Neill]

For this design Max are you proposing to have both the Local and RemoteConnection classes reference the Data class directly and not through an interface?
I would very much like to program to an interface that would tie the remote and local Data classes together but without causing my local Data object to have to throw RemoteException or at the very least IOException.
To get around this I currently have my LocalConnection object have a direct reference to a Data instance and not an interface, the same goes for my RemoteData object that resides in my RemoteConnection object. This way the two objects need only process the exceptions that are actually thrown by Data.
The problem is that RemoteData implements the interface RemoteDataInterface in accordance with RMI whereas my local Data implements no interface which seems incorrect to me. Has anyone else got any better ideas?
Many thanks Sam

[Max Habibi]

Sam, I'm not sure I understand your design. Can you break down for me how RemoteConnection uses a RemoteData object(namely, RemoteData), but doesn't have to deal with RemoteExceptions?

Ultimately, some class, somewhere, is going to have to know that it's working with a Remote Data object. There are a lot of good ways to deal with that issue, but I don't think you're going to be able to treat Data and RemoteData exactly the same way without somehow obscuring that fact that a RemoteException is being thrown.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ April 08, 2003: Message edited by: Max Habibi ]
[ April 08, 2003: Message edited by: Max Habibi ]

[Sam O'Neill]

Sorry Max I'll try and be a little clearer:
I have a ConnectionInterface that has the following methods:

public interface ConnectionInterface {
    public DataInfo[] search(..);
    public String modify(..);
    public Sting[] getHeaders(..);
    public DataInfo[] getData(..);
    public String[] getUniqueValues(..);
}

All of these methods are declared as throwing DatabaseException which I am using as the base class for all exceptions thrown by all implementing classes so my client app only has to handle this type.
I then have a LocalConnection object and RemoteConnection object as the implementing classes.
In LocalConnection I simply throw DatabaseException and in RemoteConnection I catch
any RemoteExceptions, log them, convert them to DatabaseExceptions and then rethrow them.
so far so good.
My issue is that LocalConnection refers to a Data instance whereas RemoteConnection refers to a RemoteData instance that implements the RemoteDataInterface. The Data instance in LocalConnection does not implement any interface whereas RemoteData does (the RemoteDataInterface has all the methods of Data, has all methods throw RemoteExceptiuon and extends Remote.) By the way I am using RMI.
I don't like the fact that RemoteData and Data do not implement the same interface but can see no way round this without forcing LocalConnection to have to catch RemoteExceptions which the adapter class is designed to irradicate.
Is it okay to reference a Data instance directly and not have both Data and RemoteData implement the same interface?
Thanks alot Sam

[Max Habibi]

Is it okay to reference a Data instance directly and not have both Data and RemoteData implement the same interface?

As you're describing it(that is, RemoteData offers all of the methods that Data does), I think it's fine. However, there is a middle ground. You could have an interface that both Data and RemoteData implemented(Say IDB).
M
M

[Sam O'Neill]

Ah but if Data and RemoteData implement the same interface and I program to the interface I will have to catch extra exceptions for my local Data class so will be back where I started.
Or else I will have two different interfaces that are identical except for the exceptions they throw - one would be implemented by my Remote data class, would have all the methods of the Data class, would extend Remote and throw RemoteException in addition to DatabaseException.
The other would simply throw DatabaseException and would also have all the methods of the Data class, would be implemented by Data and a RemoteDataWrapper class that would catch the RemoteExceptions thrown by RemoteData and then just throw DatabaseException.
Instead I suppose I could just have a single interface representing the methods of the Data class that throws 2 broad kinds of Exceptions i.e. IOExceptions and DatabaseExceptions and just make peace with the fact that I have to catch the IOExceptions for local mode when they are never thrown under the assumption that between local and remote mode there will never be exceptions thrown - regardless of any changes in underlying implementation - that do not fall under these two categories?
Sorry Max I am not sure what you mean by

(Say IDB)
{/quote]
Sorry for all the questions - I am finding this the most challenging part of the assignment
Many thanks Sam