db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject SQLExceptions and OutOfMemoryExceptions
Date Tue, 22 Nov 2005 18:28:46 GMT
Somewhere in the JDBC specs/api/tutorial it says that JDBC drivers
should throw SQLExceptions rather than generic exceptions. Thus a
SQLException is preferred to a NullPointerException.
[I can't find that text now, though :-(]

For out of memory exceptions, this causes somewhat of a problem. I have
code that fails gracefully if an OutOfMemoryException is thrown during
establishment of a connection. The issue is that trying to create the
new SQLException will fail due to an OutOfMemoryException. :-(

One work-around is to pre-allocate a static singleton SQLException for
this out of memory case, there are two problems with this:

- The original OutOfMemoryException cannot be chained to the singleton,
thus some useful information is lost (the original stack trace).

- Looking forward, there would need to be several (many?) singleton
SQLExceptions, for example the one I'm experimenting with has a SQLState
starting with 08 indicating a connection failure. E.g. an
OutOfMemoryException during an executeQuery would need a SQLException
with a different SQLState.

The other alternative is to directly throw the OutOfMemoryException as
this requires no new object allocation. The problem with this is that it
is less natural for applications, which will be catching SQLException
but most likely not OutOfMemoryExceptions. And it removes the
possibility of using the JDBC SQLException sub-classing to indicate that
the operation is re-tryable.

Maybe there's also the option of trying to allocate a new SQLException
and if that fails revert to using the singleton, or throwing the
original OutOfMemoryException.

Any thoughts, opinions on the best approach?


View raw message