db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: SQLExceptions and OutOfMemoryExceptions
Date Tue, 22 Nov 2005 20:36:45 GMT

Daniel John Debrunner wrote:

>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 :-(]
That is correct where possible a SQLException is the correct error.  You 
can set it cause, starting in JDBC 4 to the real culprit.

>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. :-(
Not sure you want to jump through hoops for an OutOfMemoryException, i 
do not think it is worth it.

>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.
If you are out of memory, will there ever be a chance to create a new 
SQLException object?

>Any thoughts, opinions on the best approach?

View raw message