What about the SQLStates that are returned?  Some SQL State Class values might be appropriate.  Yes JDBC 4 will help somewhat


Kathey Marsden wrote:
Daniel John Debrunner wrote:

Kathey Marsden wrote:


Daniel John Debrunner commented on DERBY-254:


I'm not sure Derby should be recommending checking the error code for an exception, I don't think today it's specified as any part of the documentation that the error code is a severity. Use of the error code is vendor specific and will result in non-portable programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.


So with the product as is, (before JDBC 4.0) what is the recommended way
to check if an exception makes a connection invalid.  Currently I know
there are users that are using the error codes (Exception Severity)?

Execute a simple statement against the connection, e.g. VALUES 1.

Is the severity error code even portable between embedded and the client

Sadly, the  client uses different numbers for the same  meaning ,  (I
won't even mention what those numbers are!)

So, the take home for me is.

1) There is not really an efficient way to do this for JDBC3.0 but
JDBC4.0 will be better.
2) We don't want folks to use those error codes at all.

Moving forward  I think we should
1) Encourage those folks that are using the error codes to stop.
2) Not change  the error codes.  Since we don't want to publish them,
there seems no point in changing them to anything.