Sorry it was not a question, i was commenting that the SQLState might be
a better way then the error code today to understand the error, your
milage might vary though driver to driver. Error handling is definitely
not pretty today in JDBC from a portability point of view
David W. Van Couvering wrote:
I'm not sure I understand your question, but yes, as part of the work
on internationalizing the SQL Exception messages I am also making sure
the exceptions return a useful SQL State. Where the exception is
identical with an exception already thrown on the embedded driver, I'm
going to use the same SQL State. For exceptions that are unique to
the client driver, I'm going to create new SQL States using the
existing SQL State class for Derby JDBC errors, XJ0.
David
Lance J. Andersen wrote:
What about the SQLStates that are returned? Some SQL State Class
values might be appropriate. Yes JDBC 4 will help somewhat
lance
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
driver?
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.
Kathey
