You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2006/04/21 01:25:10 UTC
Help: NetAgent.java has placeholders in hardcoded messages
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
Re: Help: NetAgent.java has placeholders in hardcoded messages
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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
>
Re: Help: NetAgent.java has placeholders in hardcoded messages
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
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