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

NX: URLyBird 1.2 - Handling IOExceptions

 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
     
    Vlad Rabkin
    Ranch Hand
    Posts: 555
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Jim Yingst
    Wanderer
    Sheriff
    Posts: 18671
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I agree with Vlad here.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic