• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Dealing with Exceptions

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am just thinking about how to deal with occurring IOExceptions in the Data Access class.

I thought about the following possibilities:

1) log and ignore

2) use a RuntimeException

3) subclass (for example) RecordNotFoundException

I thought about using RuntimeExceptions, catching them in the Viewer and presenting some useful information for the user.

What do you guys think ?
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy, Daniel!

1) log and ignore



Hum... I don't think that would be a good approach. If an IOException occurs, the execution of the program shouldn't continue.

2) use a RuntimeException



I think that, in this case, it is the best option, especially because the methods of the interface do not include IOException in their signatures.

3) subclass (for example) RecordNotFoundException



Hum... no. Because IOException isn't a RecordNotFoundException.

What I did was create a record cache, so that I didn't have to deal with these exceptions. When the application starts, all records are put in a cache, and when the application finishes, everything is written back to the .db file. So, if you call update(), then no way an IOException will occur.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Daniel,

Can't agree more with Roberto, he is spot-on. The most desirable approach is creating a DAOException or DBException (which should extend RuntimeException, otherwise you can't implement Sun's interface) and wrap the IOException in it. Certainly not just logging (and/or ignoring), because who will read the log and how will user know problem occured during his updating?

And I also used a record cache, because you'll end up with simple code and you don't have to bother with IOExceptions being thrown when your updating, reading or creating a record.

Kind regards,
Roel
 
Daniel Breitner
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I also decided to subclass RuntimeException but I didn´t like the cache - approach.

In case the server collapses I will lose all changes .

If an IOException occurs - what does that mean? It means that there will be a serious problem with the file i am working on.
This error might also occur when you run a cache but you won´t notice it, will you ?
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Daniel,

Both your cons for the record cache you are mentioning in your previous post are indeed 2 of the main problems of that approach. I addressed these issues in my choices.txt and I suggested some solutions on how to handle them.

You are of course free to use any approach you want, the only thing I can say that it's a simple and easy approach and I'm very glad I followed the record cache approach.

Kind regards,
Roel
 
Daniel Breitner
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing I also thought of was :

What if the datafile rapidely increases in size ? At one point you will have to swap some records back to the file, while caching others.

That´s too complicated for me ;) ... i skip caching
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Daniel Breitner wrote:What if the datafile rapidely increases in size ? At one point you will have to swap some records back to the file, while caching others.

Again that's antoher drawback and again I addressed it in my choices.txt (so I didn't have written special code for this one). for example: load only those records with today's date or a date in future. Just for booking it has no use to load records with a date in the past.

Kind regards,
Roel
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic