Hum... I don't think that would be a good approach. If an IOException occurs, the execution of the program shouldn't continue.
2) use a RuntimeException
I think that, in this case, it is the best option, especially because the methods of the interface do not include IOException in their signatures.
3) subclass (for example) RecordNotFoundException
Hum... no. Because IOException isn't a RecordNotFoundException.
What I did was create a record cache, so that I didn't have to deal with these exceptions. When the application starts, all records are put in a cache, and when the application finishes, everything is written back to the .db file. So, if you call update(), then no way an IOException will occur.
Can't agree more with Roberto, he is spot-on. The most desirable approach is creating a DAOException or DBException (which should extend RuntimeException, otherwise you can't implement Sun's interface) and wrap the IOException in it. Certainly not just logging (and/or ignoring), because who will read the log and how will user know problem occured during his updating?
And I also used a record cache, because you'll end up with simple code and you don't have to bother with IOExceptions being thrown when your updating, reading or creating a record.
I also decided to subclass RuntimeException but I didn´t like the cache - approach.
In case the server collapses I will lose all changes .
If an IOException occurs - what does that mean? It means that there will be a serious problem with the file i am working on.
This error might also occur when you run a cache but you won´t notice it, will you ?
Both your cons for the record cache you are mentioning in your previous post are indeed 2 of the main problems of that approach. I addressed these issues in my choices.txt and I suggested some solutions on how to handle them.
You are of course free to use any approach you want, the only thing I can say that it's a simple and easy approach and I'm very glad I followed the record cache approach.
Joined: Nov 13, 2008
One thing I also thought of was :
What if the datafile rapidely increases in size ? At one point you will have to swap some records back to the file, while caching others.
That´s too complicated for me ;) ... i skip caching
Daniel Breitner wrote:What if the datafile rapidely increases in size ? At one point you will have to swap some records back to the file, while caching others.
Again that's antoher drawback and again I addressed it in my choices.txt (so I didn't have written special code for this one). for example: load only those records with today's date or a date in future. Just for booking it has no use to load records with a date in the past.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com