It seems to me that these messages can never ever been verified. Also
in the case where values are provided, it does not match the leading
text. (E.g., location is given as the first parameter, but should have
been the third.) See my comment in another thread
http://article.gmane.org/gmane.comp.apache.db.derby.devel/5822
In my opinion, such detailed debug information does not belong in
standard SQL exceptions.
--
Øystein
David W. Van Couvering wrote:
Hi. Can anyone explain to me how this works? In the close_ method of
client.net.NetAgent.java there is the following code:
accumulatedExceptions =
new SqlException(logWriter_, e, "A communication
error has been detected. " +
"Communication protocol being used: {0}. " +
"Communication API being used: {1}. " +
"Location where the error was detected: {2}. " +
"Communication function detecting the error:
{3}. " +
"Protocol specific error codes(s) {4}, {5}, {6}.
" +
"TCP/IP " + "SOCKETS " + "Agent.close() " +
"InputStream.close() " + e.getMessage() + " " +
"* " + "0");
Note the massive use of placeholders, and then none of the values for
the placeholders are provided.
This is repeated three times throughout the close() method as exceptions
are accumulated.
I track through to the SqlException code and the message appears to be
simply stored verbatim and ultimately a chain of SqlExceptions are
thrown to the user, with the placeholders not filled in.
I did a little test to throw this exception unconditionally and, which
is what I would have expected, I get the following text:
> java.sql.SQLException: A communication error has been detected.
Communication
protocol being used: {0}. Communication API being used: {1}. Location
where the
error was detected: {2}. Communication function detecting the error:
{3}. Protoc
ol specific error codes(s) {4}, {5}, {6}. TCP/IP SOCKETS Agent.close()
InputStre
am.close() blahblah * 0
Am I missing some magic here? Or is this just a bug that was never
uncovered?
Thanks,
David
