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

How to handle IOExceptions in the data class

 
No�l Verdurmen
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,

I have a problem that has been bothering me for a while now.

My data access class should throw no IOExceptions, since it implements a given interface called DB. But some IOExceptions will have to be caught or thrown in the data access class (I suppose).

I can think of three ways to deal with this:
1) Let the data access class implement two interfaces, thus also an interface which throws IOExceptions, or
2) Catch IOExceptions in the data access class and let the read/update/... methods return e.g. -1 to let the client know something went wrong, or
3) Catch the IOExceptions in the data access class and display some dialogs that tell the user something about the IOException that happened. (I am actually in doubt if I can do this over the network connection ...)

I do not really like any of these solutions, because they do not seem to be the solution the specification asks for.

How are these solutions, and does anybody have a better solution?

Thanks,
 
Anton Golovin
Ranch Hand
Posts: 527
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by No�l Verdurmen:
Hi everyone,

I have a problem that has been bothering me for a while now.

My data access class should throw no IOExceptions, since it implements a given interface called DB. But some IOExceptions will have to be caught or thrown in the data access class (I suppose).

I can think of three ways to deal with this:
1) Let the data access class implement two interfaces, thus also an interface which throws IOExceptions, or
2) Catch IOExceptions in the data access class and let the read/update/... methods return e.g. -1 to let the client know something went wrong, or
3) Catch the IOExceptions in the data access class and display some dialogs that tell the user something about the IOException that happened. (I am actually in doubt if I can do this over the network connection ...)

I do not really like any of these solutions, because they do not seem to be the solution the specification asks for.

How are these solutions, and does anybody have a better solution?

Thanks,


#2 is what I will be doing. IOExceptions can be converted into SecurityExceptions, as well, with documenting this design decision, as data integrity is a security issue. However, personally I will be going with zero-length arrays and -1.
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

I'm not sure what your data access interface is, but in mine all of the methods are declared to throw some sort of Exception. If your methods are declared to throw some subclass of Exception, what about about catching IOExceptions in your data access methods and throwing the exceptions you can throw - thus getting an exception back to the client where you can show dialogs or whatever you want to the user? Perhaps chaining exceptions is the way to go here?

My reason is that I'm not sure if error codes are a bad idea:

In the Sierra/Bates book, p594, it says "Do not return error codes!... use an Exception... if you really want to annoy an assessor, use error codes as return values... Even one method might do the trick"

I am going to really, really try to avoid them in my project.

Michal
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michal Charemza:
Hey,

I'm not sure what your data access interface is, but in mine all of the methods are declared to throw some sort of Exception. If your methods are declared to throw some subclass of Exception, what about about catching IOExceptions in your data access methods and throwing the exceptions you can throw - thus getting an exception back to the client where you can show dialogs or whatever you want to the user? Perhaps chaining exceptions is the way to go here?

My reason is that I'm not sure if error codes are a bad idea:

In the Sierra/Bates book, p594, it says "Do not return error codes!... use an Exception... if you really want to annoy an assessor, use error codes as return values... Even one method might do the trick"

I am going to really, really try to avoid them in my project.

Michal


I gave that one a try, but in my interface the findByCriteria method doesn't throw any exceptions, so you are stuck with returning a null instead of an empty vector to indicate that.

There are other choices that were not described on this thread:

4) define a runtime exception and uses that to wrap the IOExceptions, that way you can use the cause() method to recover the original exception.

5) log the exception and close the server. (or the whole app if in standalone mode), just call System.exit(). IOExceptions are rarely recoverable on files, and continued use is likely to aggrevate the problem.

6) provide a means using the Observer pattern to allow the Data class to send back IOExceptions to its client. Just add an addIOFailureListener method to your Data class. This is high OOD, but probably overkill.

Note that your network sockets or RMI will also generate IOExceptions that will need to dealt with. This can be solved easily using option 4 or 6.

I favour option 4.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi No�l,

If you catch an IOException in your Data class, what are you going to do from that point onwards? That is, what state will your system be in?

If your answer is that you cannot guarantee that future operations on the data file will be safe, then you might want to consider throwing a RuntimeException - something to indicate that the system is no longer working.

Regards, Andrew
 
No�l Verdurmen
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all the answers, they are really useful.

Michal,

I'm not sure what your data access interface is, but in mine all of the methods are declared to throw some sort of Exception


Some methods throw a RecordNotFoundException, some a SecurityException, some both, and the find-method throws none. I think I can wrap some IOExceptions in RecordNotFoundException (e.g. FileNotFoundException), but not all of them since that would change the meaning of the RecordNotFoundException:
Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file

and I think of that as a violation of the spec.
By the way, you convinced me not to use error codes.


Peter,
define a runtime exception and uses that to wrap the IOExceptions, that way you can use the cause() method to recover the original exception.

I like that one. I think I am going to combine this solution and the exception chaining solution.

Andrew,
If you catch an IOException in your Data class, what are you going to do from that point onwards? That is, what state will your system be in?

That depends of the kind of IOException. E.g., if it is a FileNotFoundException, I think i should give the user the option to specify the location of the database and keep the system running.
If it is another kind of IOException, I am actually not sure what to do...
Would a read that failed make the system instable? Probably it would, and from the answers here I conclude the best solution is to throw a RunTimeException.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by No�l Verdurmen:
Thanks for all the answers, they are really useful.

Michal,

That depends of the kind of IOException. E.g., if it is a FileNotFoundException, I think i should give the user the option to specify the location of the database and keep the system running.
If it is another kind of IOException, I am actually not sure what to do...
Would a read that failed make the system instable? Probably it would, and from the answers here I conclude the best solution is to throw a RunTimeException.



I detect the FileNotFound when running the constructor, which isn't defined in the interface so I'm free to deal with it properly. All other IOExceptions are fatal so I throw a runtime exception called DataException that uses chaining to wrap the original cause.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic