db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: SQLException and missing stack trace
Date Fri, 03 Feb 2006 20:31:51 GMT
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 <Knut.Hatlen@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
>>
>>
> 
> 
> 

Mime
View raw message