Thanks, Øystein, that was what I determined also. I fixed the placement
of arguments so they are correct. But I have to think about your point
of this information not being useful. I tend to agree, I think the
stack trace should be sufficient actually. There's not a lot of useful
information here.
So if nobody is of an opposite opinion, I can turn it into a simple message:
"A communication error has been detected: {0}" where {0} is the message
of the underlying exception. I can then chain the underlying exception
and I think that should be sufficient. It's not like we would ever use
anything *besides* TCP/IP and sockets...
David
Øystein Grøvlen wrote:
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
