Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception handling again

 
Tobias Nettels
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are many threads about this topic with different solutions. I have another idea which was not discussed here yet.
Background:
The db interface methods createRecord, deleteRecord, updateRecord not throw checked exception like IOException. I interpret this that Sun don't assign these methods for any IO like writing to the data file.
So I seperate the logical create/delete/update part from the physical part of these operation.
For example the updateRecord method creates a record in the data cache and a subsequently called methed persistRecord manages the writing of the updated record to the data file.
The db adapter class then calls lockRecord, updateRecord, persistRecord, unlockRecord. updateRecord throws all database related exceptions and persistRecord throws the IOExceptions which may occur by writing. In my case the adapter chained these exceptions to a DatabaseException which is chained from the gui controler to a controller exception. But anyway the adapter could also throw the database exceptions like RecordNotFoundException etc and the IoExceptions seperatly.
So there is no trouble with the exceptions - no need for chaining or wraping IOExceptions in checked ones, for subclassing exceptions etc.. You (the client or the adapter) just have to call the 2 methods instead of one.
What do you think about it?
Regards Tobias
[ March 31, 2004: Message edited by: Tobias Nettels ]
[ March 31, 2004: Message edited by: Tobias Nettels ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tobias,
What do you think about it?

As your previous post is dated before I registered myself on JavaRanch, I guess that I can tell you first "Welcome to JavaRanch and this forum!" as we don't know each other yet.
Your solution seems OK at first sight.
But this:
The db adapter class then calls lockRecord, updateRecord, persistRecord, unlockRecord. updateRecord throws all database related exceptions and persistRecord throws the IOExceptions which may occur by writing.

looks wrong. Your "db adapter" should be able to talk to the provided interface, which doesn't define any "persistRecord" method.
I think that with your "persistRecord" method solution, you just shifted the IOException issue, with the risk of breaking the instructions (which implicitly expect us to be able to code to the provided interface).
What about some simple "DataException extends RuntimeException" to wrap all IOExceptions which the DBAccess interface doesn't allow you to throw?
Regards,
Phil.
[ March 31, 2004: Message edited by: Philippe Maquet ]
 
Tobias Nettels
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Philippe,
thanks for your wellcome. You didn't know me, but I knew you, cause I read some of your posts which I always enjoy reading and find helpfull.

And thanks for your answer, you found the weak point of my construction. I think I have to change this part next time.
All the best
Tobias
 
Tobias Nettels
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about some simple "DataException extends RuntimeException" to wrap all IOExceptions which the DBAccess interface doesn't allow you to throw?

I don't like wrapping checked expressions in unchecked. For my taste its too much against the idea of checked expressions.
I now prefer a mixed solution.
The update and delete methods uses IORecordNotFoundExpression, a subclass of the RecordNotFoundExpression which chains the IOExceptions. RecordNotFoundExpression indicates that the record is generally or logically not found where as IORecordNotFoundExpression indicates that its physically not found (cause the database could not be accessed). Thats not too wrong ;-)
In case of the create method I return -1 when an IOExceptions occurs indicating that something went wrong. This is a common behavior for methods like this espacially in languages which don't support exception handling.
Any occuring IOException will be logged and can also be find out by calling the initCause of RecordNotFoundExpression.
Make sense?
Regards Tobias
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tobias,
Sorry for the delay, but I was on vacation for a week.
Your solution sounds defendable, but what do you do with findByCriteria() (which doesn't throw any exception, at least in my version of the assignment)?
Regards,
Phil.
 
Tobias Nettels
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Philippe,
no matter, I was on vacation too!
The findByCriteria returns a long array with no elements if there a no matches.
Regards
Tobias
[ April 17, 2004: Message edited by: Tobias Nettels ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic