Hi Wickes,
I am sitting with the same issue, I am trying to implement the create method but the provided interface only throws DuplicateKeyException. I am not going for the data cache option but instead direct read/write. So, when I want to read the data or update the data in this method, an IOException may occur and I don't know how to throw this to the calling method.
You've basically three ways of dealing with the IOException issue:
chain the IOException in some provided one chain it in some RuntimeException of your own (DataException?) that you throw throw some RuntimeException of your own (DataIOException?). Which solution to choose?
If you're lucky enough (as me), you can eliminate solution 1 immediately because one of the provided methods where you may encounter some IOException doesn't throw any exception at all (in my case: findByCriteria()), so no exception that you could use as a wrapper.
So in my case, solution 1 was impossible to implement. But even in the case it'd be possible, I wouldn't have choosen it. Exception chaining is there to *simplify* exceptions handling: gather multiple (possibly many) checked exception types together in some wellknown exception type which is easy to catch. Not only it makes the caller's life easier, but it's indispensable each time you want to publish some generic interface (as no new or broader checked exception may be thrown from a method implemented from an interface - same as the overriding rule). Good example of this: the ServletException in the Servlets/JSP API, a generic checked exception declared to act as a wrapper to any checked exception you'd decide to pass "above" (a SQLException for instance).
But in our assignment, it's the contrary: we've *multiple* declared checked exceptions (DuplicateKeyException, RecordNotFoundException, SecurityException, ...), all specialized, and mainly one undeclared checked exception: IOException. So, even if findByCriteria() throws some exception in your assignment, it's clear that it's a bad solution: how to wrap in a consistent manner, and how to *document* it, as the wrappers would change from one method to another?
Now between solutions 2 and 3, I do prefer 2 but it's probably more a question of personal preference.
Regards,
Phil.
[ June 08, 2004: Message edited by: Philippe Maquet ]