Hi, In my initial design and my initial implementation, I do the following:
However, I am not suggesting that this it the best way, although it is one way of doing it. If, right at this very minute, you read over the last 15 posts in this news group, you will find a posting about handling exceptions which Phil gave a very strong, positive response to. I plan to study this post in detail during my next iteration phase. It turns out that I have this posting link: Topic: Exception handling using socket connection https://coderanch.com/t/185087/java-developer-SCJD/certification/Exception-handling-socket-connection I would still recommend looking over the last 15 posts, as this particular topic item has been coming up a lot recently, and there was other good advice offered by others. Again, the "last 15 posts" means as of right at this minute (since the order of the postings changes over time). Thanks, Javini Javono
Originally posted by Fl�vio Fran�a: How can I notify an IOException when deleting from the database file?
These are the two main ways to do this: 1) Catch the IOException and throw a RecordNotFoundException that chains (or wraps depending on what your RecordNotFoundException class supports)the IOException as its cause. For example:
2) Derive a subclass of RuntimeException. Catch the IOException and throw a subclass of RuntimeException that chains the IOException as its cause. For example:
Method 1 requires the client to handle the RecordNotFoundException, but it's up to the client to examine the cause of the exception. Method 2 doesn't require the client to handle the exception, but doesn't make the implicit claim that an IOException problem is a variety of RecordNotFoundException. On balance I think method 1 is the better solution in this case. Others may disagree.
Originally posted by Fl�vio Fran�a: Yes, I prefer method 1 too, but it sounds strange on the method create wich throws a DuplicatedKeyException. So, I think I'll use the second one.
That's a good point about the create method. I used method 1 to wrap the IOException within a DuplicateKeyException, but I wasn't as happy doing so as I was wrapping IOException in RecordNotFoundExceptions for the other database methods. I was willing to go through these contortions in order to get the benefit of having a checked exception. Of course, I understand if someone's not willing to do the same. The inability to change the Sun interface leaves us with less than ideal alternatives. You have to go with the one that makes the most sense to you.