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
an examiner calls create(record) and gets IllegalStateException with a message: DB not initilized, call init() first
so she/he looks through the documentation and sees that that there is an init() throws IOException declared in an interface DBUrlyBird extends DB
he also sees that Data implements DBUrlyBird is a singleton and the docs provide the information how to get an instace
while 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 ?
There is a reason for throwing a generic DBException: your interface should hide implementation details. If you throw an IOException it seems you are using file I/O. And what if you have to create an implementation of your interface for a RDBMS, like MySQL. You probably have to deal with SQLExceptions (instead of IOExceptions). Using this DBException solves this issue in a clean nice way.
That's right. The scenario I provided was just an example. I was rather thinking of checked exceptions (not specifically of IOException). Anyway, thanks for pointing this out. That's is a very useful infomration for all of us.