• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception Handling...

 
Richard denSeig
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic