Hi,
My Data class which implements DBAccess throws exceptions which are not listed in the interface. For example, the createRecord() method throws IOException, but the interface only declares DuplicateKeyException to be throwable.
I've been reading about possible solutions, and have identified 3:
1. Chain the IOException to the DuplicateKeyException
Personally, I don't think this is at all appropriate in this case because I believe that two exceptions should only be chained if they are related. For example one might want to chain a very specific exception to a more general exception (and throw the latter).
2. Chain the IOException to an unchecked exception
I don't like this the idea of mixing together checked/uncecked exceptions. Also, a book I've read says that you should never throw unchecked exceptions yourself, as they are indicative of a programming error.
3. Return an error code
Rather than throwing an exception to indicate an error, catch the exception and return an error code, e.g. -1 in the case of createRecord. This seems the best of a bad lot to me, but is a procedural rather than OO technique.
I'd be interested to hear others think is the best solution to this problem.
Cheers,
Dan
My Data class which implements DBAccess throws exceptions which are not listed in the interface. For example, the createRecord() method throws IOException, but the interface only declares DuplicateKeyException to be throwable.
I've been reading about possible solutions, and have identified 3:
1. Chain the IOException to the DuplicateKeyException
Personally, I don't think this is at all appropriate in this case because I believe that two exceptions should only be chained if they are related. For example one might want to chain a very specific exception to a more general exception (and throw the latter).
2. Chain the IOException to an unchecked exception
I don't like this the idea of mixing together checked/uncecked exceptions. Also, a book I've read says that you should never throw unchecked exceptions yourself, as they are indicative of a programming error.
3. Return an error code
Rather than throwing an exception to indicate an error, catch the exception and return an error code, e.g. -1 in the case of createRecord. This seems the best of a bad lot to me, but is a procedural rather than OO technique.
I'd be interested to hear others think is the best solution to this problem.
Cheers,
Dan