File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Exception Handling... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Exception Handling..." Watch "Exception Handling..." New topic
Author

Exception Handling...

Richard denSeig
Ranch Hand

Joined: Apr 06, 2002
Posts: 32
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??

Your comments very welcome.
-Richard
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
Richard denSeig
Ranch Hand

Joined: Apr 06, 2002
Posts: 32
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
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Exception Handling...
 
Similar Threads
Interface to Data
Design feedback
Single Data Interface Justification
Connection Object for lock/unlock...?
Design questions (with RMI)