The way to communicate an IOException to a Data class method caller, without changing the methods signatures, has been discussed already : I'll wrap it in a custom runtime exception (DataIOException for example) that I will document. But now I wonder if it does make sense (except for EOFExceptions) to let subsequent calls to run successfully or if it is better to :
flag the database as "corrupted"
while the flag is on (reset when the db is reopened), throw DataIOException in all methods that read and/or write in the DB without attempting to do it
The main idea is to avoid to read/write further in the DB from the moment you know it is corrupted. What do you think about it ? Regards, Philippe.
Hi, I beleive it is your personal design decision. My strategy is - to let the clients work as long as possible. - try not inhance design more than it is needed, because by doing that we can breach specification. I have seen here a lot of people, who tried to make inhancement (e.g time-outs for Locking) and failed... So, I will not do, what U suggest.
0
