• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Throwing exception on closing the data file

 
Kevin Broderick
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I don't know what to do here. As with all exceptions being raised inside the data class, they are all thrown up to the gui, but there is this situation where on writing back out to the file I must handle an IOException. I call on writing the file when I'm closing down the application so I cannot propagate it up to the gui. I suppose it would be right to catch the exception and use JOptionPane message informing the user of whatever went wrong on writing the file inside the data class. I believe that this is the way to do it but I'm just writing this here in case any of you ranchers here have a better way.

Cheers in advance

Kevin.
 
David Byron
Rancher
Posts: 175
Clojure Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kevin Broderick wrote:...there is this situation where on writing back out to the file I must handle an IOException. I call on writing the file when I'm closing down the application so I cannot propagate it up to the gui. I suppose it would be right to catch the exception and use JOptionPane message informing the user of whatever went wrong on writing the file inside the data class. I believe that this is the way to do it....


If you're storing the full database in memory and operating only on your cache until the user closes the app, then an error indicating that the file could not be written should be propagated all the way to the GUI. It should declare in the boldest way possible that all transactions that have occurred in that session are about to be blown into the atmosphere because of an I/O problem and that shutdown has been aborted!

On the other hand, if you've successfully written to the file whatever ought to be written, and you're just closing the file, you have to decide whether to (a) attempt to handle the abnormal termination (say, with a retry) or (b) swallow the error (in a self-documenting way) as inconsequential if you're quite sure it is inconsequential.

Whatever you do, be sure to explain it in your decisions doc.
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about holding the GUI open until the I/O completes?

Jim ... ...
 
Carlos Morillo
Ranch Hand
Posts: 221
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kevin,


I defined my own DataAccessException a wrapper class, which exists only to wrap low-level
exceptions specific to each storage mechanism (for example, SQLException and
IOException). When an implementation class throws an exception, it is caught,
wrapped in a DataAccessException, and then rethrown. This protects the
business layer from ripple effects caused by changes to the Data
class implementation.


HTH,


Carlos.
 
Roel De Nijs
Sheriff
Posts: 9790
101
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kevin,

It all depends when the writing back occurs. If you use a shutdownhook there is not a lot you can do, because it is a part of the termination process of the JVM. So logging is almost the only thing you can do.
When you have yourself complete control about the application (with a gui), you can call a method yourself and be able to show any possible error before exiting.

In my application I also used the shutdownhook, so I documented in choices.txt some alternative solutions to prevent minimal data loss to implement in future releases and that's it.

Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic