• 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

NX: IOException in Data class / logging

 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I'm working on the data access class of the contractor assignment, and have a question on the handling of IOExceptions:
the update method for example can throw a RecordNotFoundException or a SecurityException. When updating a record, it is however possible to get an IOException.
the same goes for the findByCriteria method (which does not throw any exception).
The question is how to handle the IOExceptions:
in the update method I can wrap the IOExceptions in a RecordNotFoundException; in the findByCriteria however I don't have such an option.
Alternative would be to only log the IOExceptions on the server side, but then the question would be how the client knows that the update went wrong...
Typing this post, I presume the right approach would be:
- to wrap the IOExceptions in RecordNotFoundExceptions (if possible)
- if it is not possible (for example for searchByCriteria), just return empty result.
- and in addition to the above: to log exceptions on the server side (just writing the ouput to the console - to avoid problems with logfiles which can't be opened)
Is this the right approach?
Greetings,
TK
 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my design, I just wraps all the exception into RecordNotDoundException, and detail the error message.
Frank
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally, I don't like the idea of using RecordNotFoundException for this. To me, RNFE is a way of saying "that record never existed, or if it did exist, it's been deleted". Not "something unexpected happened and I don't know if the record exists or not". To me, the latter is a different situation, and deserves to be treated as such. Note that the create() and find() methods do not allow RNFE anyway, so some other response must be devised for the case of an IOException during these methods. Once an alternate response is devised, we might as well try to use it for all the cases where IOException is thrown, for consistency.
Personally I think the best response is to wrap the IOException in a RuntimeException (possibly a custom subclass). This can then be caught at a higher level as desired. Probably a GUI user should see a message like:


Your request could not be completed due to an unexplained system error:
[error text]
If this problem persists, please exit and restart the program (notify server mangagement if running over network)
[checkbox] Do not show this message again.


And log the error too, of course.
Regarding the find() method, I don't like the idea of returning an empty array if there's an error. To me, that says "there are no records which match your criteria". Returning null might be slightly better, as that at least sends a different message. But something with more info would be preferable, IMO. And create() doesn't have the option - well, I suppose we could return -1 to indicate an error. (I'm certainly not using DuplicateKeyExecption to indicate IOException, that's just wrong.) I think it's much better to treat these IOExceptions consistently, in a manner that doesn't hide errors if they occur. RuntimeException seems the best option for this, IMO.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
I would try and steer clear of using return values to indicate errors - it goes against the whole philosophy of why we have exceptions, and is one of the indicators that a coder has still not completely converted to OO.
So time for a documented design decision Do you use Runtime Exceptions, or do you redesign the provided exceptions and / or change signatures on their methods? Plenty of good and bad points for both.
Regards, Andrew
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would try and steer clear of using return values to indicate errors
Oh, I agree. I was just brainstorming for things that were theoretically possible here - I added the to indicate I don't think using the return value for an error here is a good idea.
 
Thomas Kijftenbelt
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
Thanks for the advise... I changed the Data class and wrap the errors in RuntimeExceptions, which I catch at the client side.
TK
 
Evil is afoot. But this tiny ad is just an ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic