db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject SQLException conundrum
Date Wed, 11 Jan 2006 01:12:57 GMT
Looking for your thoughts on a bit of a conundrum.

It is working pretty well to migrate the client code to throw 
SQLException directly rather than org.apache.derby.client.am.SqlException.

There are some diagnostic features, however, that can't migrate, because 
they rely on extra information stored in SqlException that is not 
available in SQLException.

The alternative is to continue using SqlException internally, passing it 
up the chain to the top-level classes, and then convert it into 
SQLException.  Ths problem with this is in JDK 1.3 the stack trace is 
completely lost.  However, in JDK 1.4 and greater I can use the 
initCause() method and the stack trace is retained.

My preference is to actually to continue using SqlException and then 
convert at the top level before throwing the exception to the user (this 
is actually a common practice).  This allows us to keep our diagnostic 
info and to be able to increase it if we want to.

I can use reflection to see if the initCause() method is available, and 
call it if it's there.  For JDK 1.3 vms, I can ensure that the stack 
trace is logged prior to converting the exception.

This seems pretty reasonable to me.  Any comments?


View raw message