• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

IO Exception in DB

 
Daniel Simpson
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hate to bring this topic up again because I know it has been discussed to death in http://www.coderanch.com/t/186319/java-developer-SCJD/certification/Exception-handling-IOException-not-DB but I wanted to make sure my solution is okay.
I am caching my records into an arraylist, but when I update, create, and delete a record, I first do so in the data file before updating my cache. So what I have read, would it be okay to do something like this:


Is that how I would do that? Chain my IOException to a RuntimeException? I first thought about chaining it to a RecordNotFoundException, but that isn't really the purpose of the RNFEx. My doc says:


Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

So I don't think I should chain it to a RNFEx for errors while reading bytes. Does this solution sound okay? Is it okay that I throw a RuntimeEx? Or would it be better to subclass RNFEx? And catch the IOException and rethrow an IORNFEX? Thank you!
 
Anton Golovin
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Daniel. I think RuntimeException is ok. It is a better solution than RNFEx. However, in terms of design, it is flimsy to rely on a quirk in Java's Exception mechanism design to solve a problem. Unfortunately, it is the best way in this case.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Daniel Simpson:
So I don't think I should chain it to a RNFEx for errors while reading bytes. Does this solution sound okay? Is it okay that I throw a RuntimeEx? Or would it be better to subclass RNFEx? And catch the IOException and rethrow an IORNFEX? Thank you!


You definitely should not chain things in RecordNotFoundException, since there are methods that don't throw that exception. Using a RuntimeException is better, but you should actually define your own exception that extends RuntimeException so that you can catch it explicitly in your business logic.
 
Sven Mari�n
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it's correct to make a custom exception class which you can use to wrap the IOExceptions and others, but wouldn't it be better to make it a checked exception ? You're allowed to throw any extra application exceptions and by using this checked exception you impose your business layer to catch and treat them...
 
Sven Mari�n
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, caught my error : you can't add checked exceptions to the method identification, so indeed your custom exception must be a runtime exception. Sry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic