• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: IOException in Data class / logging

 
Thomas Kijftenbelt
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • 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
 
frank sun
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my design, I just wraps all the exception into RecordNotDoundException, and detail the error message.
Frank
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • 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.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • 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
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • 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
  • 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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic