This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hi all, In my project, my root interface (DataInterface) throws both RemoteExceptions and DatabaseExceptions. I think others here are also using a similar design: RemoteDataInterface extends DataInterface and Remote. Data implements DataInterface. Data throws Database and RemoteData throws Database and Remote exceptions. So this means that when methods in the DataInterface are invoked, Remote and Database exceptions, and in one case IOExceptions, must be caught. This is not particularly elegant...has anyone any ideas on a better strategy... I read where someone was using a wrapper to wrap the concrete DataInterface so that the RemoteExceptions would be caught in the wrapper and rethrown as DatabaseExceptions... I'd like to hear some comments about wheather this is considered good O-O practice...if it is not, what would be the alternative??
Originally posted by Richard denSeig: So this means that when methods in the DataInterface are invoked, Remote and Database exceptions, and in one case IOExceptions, must be caught.
This is an expression of the fact that applications talking to a DataInterface cannot and do not know whether they are talking to a local or a remote implementation of that interface. So they must be geared up to handle RemoteExceptions. Nothing wrong with this. An application which knows that it is always accessing a local database can use Data directly. Or, if you wish, you can define a LocalDataInterface sub-interface of DataInterface that omits the RemoteExceptions.
I read where someone was using a wrapper to wrap the concrete DataInterface so that the RemoteExceptions would be caught in the wrapper and rethrown as DatabaseExceptions...
To some extent that is a matter of taste. I wouldn't do this, because in my experience network transport errors (which are usually transient) often need to be handled differently from server errors. From that point of view it's both proper and convenient that they are represented by completely different exception types. But you can argue for both alternatives. - Peter
Joined: Apr 06, 2002
Hi Peter, thanks for your insight on this...I am still not totally comfortable with having to catch remote exceptions in code when mode is local...but, I think the problem is due to the lineage of these exceptions... Maybe RemoteExceptions should not be checked exceptions but Runtime...oh, well...that is well beyond the scope of assignment... What you have said makes me more comfortable with having the exceptions in the code... least for now... thanks, Richard
Peter den Haan
Joined: Apr 20, 2000
Originally posted by Richard denSeig: I am still not totally comfortable with having to catch remote exceptions in code when mode is local...
I would certainly hope that the very same is code also used when the mode is not local! Otherwise something is probably wrong in your design. So the code does not know (or care) if the mode is local or remote, and should be prepared to handle either situation correctly. - Peter