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 Knut Anders Hatlen <Kn...@Sun.COM> on 2006/02/03 20:47:19 UTC
SQLException and missing stack trace (was: svn commit: r371561 ...)
David, I didn't see you responding to this mail. I'm resending it with
a different subject which is hopefully less likely to be regarded as
junk by your mail filter. :)
Thanks,
Knut Anders
Knut Anders Hatlen <Kn...@Sun.COM> writes:
> Hi David, I'm sorry that I didn't notice it earlier, but I have found
> a problem with the following method:
>
> > Modified: db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java
> > URL: http://svn.apache.org/viewcvs/db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java?rev=371561&r1=371560&r2=371561&view=diff
> > ==============================================================================
> > --- db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java (original)
> > +++ db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java Mon Jan 23 07:58:34 2006
> > +
> > + /**
> > + * Convert this SqlException into a java.sql.SQLException
> > + */
> > + public SQLException getSQLException()
> > + {
> > + if ( wrappedException_ != null )
> > + {
> > + return wrappedException_;
> > + }
> > +
> > + // When we have support for JDBC 4 SQLException subclasses, this is
> > + // where we decide which exception to create
> > + SQLException sqle = new SQLException(getMessage(), getSQLState(),
> > + getErrorCode());
> > +
> > + // If we're in a runtime that supports chained exceptions, set the cause
> > + // of the SQLException.
> > + if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
> > + {
> > + sqle.initCause(getCause());
> > + }
> > +
> > + // Set up the nextException chain
> > + if ( nextException_ != null )
> > + {
> > + // The exception chain gets constructed automatically through
> > + // the beautiful power of recursion
> > + sqle.setNextException(nextException_.getSQLException());
> > + }
> > +
> > + return sqle;
> > + }
>
> I think
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
> {
> sqle.initCause(getCause());
> }
>
> should have been
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
> {
> sqle.initCause(this);
> }
>
> It is the SqlException that is the cause of the SQLException. The
> cause of an SqlException is often null, and if we pass the null value
> to SQLException.initCause(), we lose all of the driver internal stack
> trace, and it makes debugging very difficult. All we get in the stack
> trace is SqlException.getSQLException(), the top-level JDBC method and
> the application stack.
>
> There is a similar problem in SqlWarning.getSQLWarning().
>
> --
> Knut Anders
>
>
Re: SQLException and missing stack trace
Posted by Sunitha Kambhampati <ks...@gmail.com>.
David W. Van Couvering wrote:
> Hi, Sunitha. Did you log a JIRA for this? I didn't see it...
>
I just did. http://issues.apache.org/jira/browse/DERBY-1117
Thanks,
Sunitha.
Re: SQLException and missing stack trace
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Sunitha. Did you log a JIRA for this? I didn't see it...
David
David W. Van Couvering wrote:
> Yes, I agree this is a bug, thanks for catching this Sunitha.
>
> David
>
> Sunitha Kambhampati wrote:
>
>> Hi all,
>>
>> I came across this when I was fixing another issue and realized that
>> the error message didnt show me the actual underlying exception/cause.
>> cause is being lost in the following constructor in SqlException
>>
>> public SqlException(LogWriter logwriter,
>> MessageId msgid, Object[] args, Throwable cause)
>> {
>> this(
>> logwriter,
>> msgutil_.getCompleteMessage(
>> msgid.msgid,
>> args),
>> ExceptionUtil.getSQLStateFromIdentifier(msgid.msgid),
>> ExceptionUtil.getSeverityFromIdentifier(msgid.msgid));
>> }
>>
>> maybe we should add setThrowable(cause) so we dont lose track of it.
>> Thanks,
>> Sunitha.
Re: SQLException and missing stack trace
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Yes, I agree this is a bug, thanks for catching this Sunitha.
David
Sunitha Kambhampati wrote:
> Hi all,
>
> I came across this when I was fixing another issue and realized that the
> error message didnt show me the actual underlying exception/cause.
> cause is being lost in the following constructor in SqlException
>
> public SqlException(LogWriter logwriter,
> MessageId msgid, Object[] args, Throwable cause)
> {
> this(
> logwriter,
> msgutil_.getCompleteMessage(
> msgid.msgid,
> args),
> ExceptionUtil.getSQLStateFromIdentifier(msgid.msgid),
> ExceptionUtil.getSeverityFromIdentifier(msgid.msgid));
> }
>
> maybe we should add setThrowable(cause) so we dont lose track of it.
> Thanks,
> Sunitha.
Re: SQLException and missing stack trace
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Hi all,
I came across this when I was fixing another issue and realized that the
error message didnt show me the actual underlying exception/cause.
cause is being lost in the following constructor in SqlException
public SqlException(LogWriter logwriter,
MessageId msgid, Object[] args, Throwable cause)
{
this(
logwriter,
msgutil_.getCompleteMessage(
msgid.msgid,
args),
ExceptionUtil.getSQLStateFromIdentifier(msgid.msgid),
ExceptionUtil.getSeverityFromIdentifier(msgid.msgid));
}
maybe we should add setThrowable(cause) so we dont lose track of it.
Thanks,
Sunitha.
Re: SQLException and missing stack trace
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
"David W. Van Couvering" <Da...@Sun.COM> writes:
> Hi, Knut, you're right, I didn't see your original email, I do have to
> have a pretty tight filter to get anything done besides read email.
>
> The intent was to "clone" the SqlException into a SQLException, but
> you're right, the stack trace and other context of the SqlException
> would be lost in the way it's done now. Thanks very much for catching
> this!
I think "thanks for running into this" would be more precise. ;)
> If the SqlException itself was caused by another exception, I have to
> make sure that history gets saved too.
That won't be a problem since that cause would be linked to the
SqlException, so you could do something like this in your application:
try {
...
} catch (SQLException sqle) {
Throwable cause1 = sqle.getCause(); // SqlException
Throwable cause2 = cause1.getCause(); // SqlException's cause
}
> I'll log a bug and take a look at this.
Thanks for looking into this. You'll probably need to update a couple
of master files as well. At least, when I had the proposed changes in
my sandbox, some of the tests failed because of extra "Caused by:"
lines.
--
Knut Anders
Re: SQLException and missing stack trace
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Knut, you're right, I didn't see your original email, I do have to
have a pretty tight filter to get anything done besides read email.
The intent was to "clone" the SqlException into a SQLException, but
you're right, the stack trace and other context of the SqlException
would be lost in the way it's done now. Thanks very much for catching
this!
If the SqlException itself was caused by another exception, I have to
make sure that history gets saved too. I'll log a bug and take a look
at this.
David
Knut Anders Hatlen wrote:
> David, I didn't see you responding to this mail. I'm resending it with
> a different subject which is hopefully less likely to be regarded as
> junk by your mail filter. :)
>
> Thanks,
> Knut Anders
>
> Knut Anders Hatlen <Kn...@Sun.COM> writes:
>
>
>>Hi David, I'm sorry that I didn't notice it earlier, but I have found
>>a problem with the following method:
>>
>>
>>>Modified: db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java
>>>URL: http://svn.apache.org/viewcvs/db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java?rev=371561&r1=371560&r2=371561&view=diff
>>>==============================================================================
>>>--- db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java (original)
>>>+++ db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java Mon Jan 23 07:58:34 2006
>>>+
>>>+ /**
>>>+ * Convert this SqlException into a java.sql.SQLException
>>>+ */
>>>+ public SQLException getSQLException()
>>>+ {
>>>+ if ( wrappedException_ != null )
>>>+ {
>>>+ return wrappedException_;
>>>+ }
>>>+
>>>+ // When we have support for JDBC 4 SQLException subclasses, this is
>>>+ // where we decide which exception to create
>>>+ SQLException sqle = new SQLException(getMessage(), getSQLState(),
>>>+ getErrorCode());
>>>+
>>>+ // If we're in a runtime that supports chained exceptions, set the cause
>>>+ // of the SQLException.
>>>+ if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
>>>+ {
>>>+ sqle.initCause(getCause());
>>>+ }
>>>+
>>>+ // Set up the nextException chain
>>>+ if ( nextException_ != null )
>>>+ {
>>>+ // The exception chain gets constructed automatically through
>>>+ // the beautiful power of recursion
>>>+ sqle.setNextException(nextException_.getSQLException());
>>>+ }
>>>+
>>>+ return sqle;
>>>+ }
>>
>>I think
>>
>> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
>> {
>> sqle.initCause(getCause());
>> }
>>
>>should have been
>>
>> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
>> {
>> sqle.initCause(this);
>> }
>>
>>It is the SqlException that is the cause of the SQLException. The
>>cause of an SqlException is often null, and if we pass the null value
>>to SQLException.initCause(), we lose all of the driver internal stack
>>trace, and it makes debugging very difficult. All we get in the stack
>>trace is SqlException.getSQLException(), the top-level JDBC method and
>>the application stack.
>>
>>There is a similar problem in SqlWarning.getSQLWarning().
>>
>>--
>>Knut Anders
>>
>>
>
>
>