Hello,
I've been thinking of how to deal with the IOException in my application and here are my thoughts.
I decided to implement a cache in the Data class. Additionally (encouraged by some people at this forum) I extended Sun's DB interafce and provided two more methods:
init() - will be called to initialize cache (MAP<Integer, Room>)exit() - will be called when application(server or standalone mode) terminates and will save records stored in the cache back in the database file
All the CRUD methods operate on the cache only so there is no problem of the IOException. Thanks to this solution I do not breake the contract of the Sun's interface.
I was looking for an information how people deal with that situation and found an interesting post
here.
Max Habibi wrote:If you interpret the requirements religiously, then maybe Sun is trying to give you a hint on the implementation they'd like to see here. That is, maybe they're telling you there shouldn't be any IO in this method. And if that's true, maybe they expect you to add the record logically. That is, maybe they expected you to cache the db in memory, and simply add/remove from that store: thus, there's no IO. Then again, maybe not. This interpretation has it's own consequences. For example, when are you supposed to reconcile the cache with the actual file? When you exit? maybe, but it sounds like a lot to intuit from a single method's signature
Simple scenario:
an examiner calls create(record) and gets IllegalStateException with a message: DB not initilized, call init() firstso she/he looks through the documentation and sees that that there is an init() throws IOException declared in an interface DBUrlyBird extends DBhe also sees that Data implements DBUrlyBird is a singleton and the docs provide the information how to get an instacewhile trying to call init() the compiler error is raised: IOException bla bla ...
What do you think of that solution ? Probably there is a lot of ways to resolve this issue but will this one be acceptable ?
I didn't find anyone who used this approach.
Thanks
RK