Hi Daniel,
I don't think that this part of the Derby api is specified. I don't
think we have any regression tests in place to guarantee that the
position of the original error in the exception graph won't change
across releases. Bear in mind that SQLExceptions have their own chaining
mechanism. So when you unravel the exception ball, you have to follow
both SQLException.getNextException() and Throwable.getCause(). I would
expect the original error to be at the end of some trajectory through
the exception graph. You may need to write an acceptance test for your
application to alert you if Derby's behavior changes across releases.
Hope this helps,
-Rick
Daniel Noll wrote:
Hi all.
I've noticed that Derby appears to be catching Throwable somewhere
internally, and thus is absorbing exceptions which should normally not
be caught. This means that ultimately the user isn't seeing the
correct exception as it is claiming a problem with the database where
they really should be seeing the error dialog about the system being
out of memory.
I can do this:
try {
connection.prepareStatement(...).executeQuery()...
} catch (SQLException e) {
if (e.getCause() instanceof Error) {
throw (Error) e.getCause();
} else if ...
}
This appears to catch situations I'm seeing in the logs, but is it
okay to assume that the OOMEs and such will only be one level deep
inside the exception hierarchy?
Daniel
