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? Dan.
