Hi Hugh,
B. Wrap it in an unchecked exception, that is, a RuntimeException or a derived subclass thereof. You can use exception chaining with RuntimeExceptions. For example,
Because it is a RuntimeException (that is, an unchecked exception) being thrown out of the method it is not necessary to identify this exception in the throws list.
You should mention it with a @throws clause in the method's javadoc comment though.
There are pros and cons for the A and B techniques.
Pros for A:
Since IOException is a checked exception you know that any clients of this method will have to handle the possibility of an IOException being thrown or the compiler will bite them.
Cons for A:
Does RecordNotFoundException really belong in an IOException? You have to convince yourself one way or the other.
Pros for B:
You don't have to believe that RecordNotFoundException really belongs in an IOException. You can subclass the RuntimeException to reflect more accurately what's going on (for instance, RecordProblemException extends RuntimeException).
Cons for B:
Because RuntimeException is not a checked exception you don't force any of the method's clients to handle the exception, they should but you can't get the compiler to bite them if they don't.
Should the Sun-specified exceptions be handled at this level? Well, if a record can't be found at the database level you're going to have to send some sort of message to client so the client can inform the user why his database operation failed. Propogating the exception is a good way to inform the client about what went wrong with the database operation.
Hope this helps,
George
[ February 17, 2004: Message edited by: George Marinkovich ]