db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
Date Thu, 20 Jul 2006 18:41:23 GMT
Hi, Knut.  Yes, it's true, this works, but I thought the whole point of 
rewriting the client so that client.am.SqlException doesn't extend 
java.sql.SQLException was so that we could directly use and throw the 
java.sql exceptions rather than our extensions of them.   This is 
important in JDBC 4 when we have so many subclasses, and there is the 
expectation that JDBC 5 may very well have more to come.

We could go back on this decision, but I don't see that it's worth it. 
What's wrong with printing out the actual exception class, which is the 
default behavior?    I don't know why we would want to build our own 
"shadow" hierarchy of SQLExceptions just to achieve this.

Note that even in the embedded code, the 40 factory creates vanilla 
java.sql exception classes and throws them.  This fix is only for 
applications running with JDK 1.5 or earlier.

I think the change I made, although a little white lie (the class is 
org.apache.derby.impl.jdbc.EmbedSQLException rather than 
java.sql.SQLException) is pretty reasonable, especially since it's only 
for older VMs, and will be unnecessary in some (distant) future when JDK 
1.5 is no longer supported.  Is there a reason you feel this isn't going 
to work?


Knut Anders Hatlen (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12422421 ]

> Knut Anders Hatlen commented on DERBY-1438:
> -------------------------------------------
> David wrote:
>> We can't override the toString() method on the network client, as
>> what's being returned to users is a vanilla java.sql.SQLException
>> (or one of its subclasses in JDBC4).  So it's going to do the
>> default behavior and there's nothing we can do about it.
> Actually, there is something we can do. The spec doesn't say that we
> can't create subclasses of the provided exception classes, so we can
> override the toString() method.
> I tried this code
>     throw new SQLFeatureNotSupportedException("some error message") {
>         public String toString() {
>             return "SQLException: " + getMessage();
>         }
>     };
> and it printed this message
>   SQLException: some error message
> not
>   java.sql.SQLFeatureNotSupportedException: some error message
>> Text written by SQLException.toString differs between client and embedded driver
>> --------------------------------------------------------------------------------
>>                 Key: DERBY-1438
>>                 URL: http://issues.apache.org/jira/browse/DERBY-1438
>>             Project: Derby
>>          Issue Type: Improvement
>>          Components: JDBC, Newcomer
>>    Affects Versions:
>>         Environment: Sun JDK 1.5
>>            Reporter: Olav Sandstaa
>>         Assigned To: David Van Couvering
>>            Priority: Trivial
>>         Attachments: DERBY-1438-rev2.diff, DERBY-1438.diff
>> The first part of the string written by SQLExeption.toString() differs
>> between the Derby client driver and the embedded driver. The embedded
>> driver writes:
>>    SQL Exception: Table/View 'DERBYDB' does not exist.
>> while the client driver writes:
>>    java.sql.SQLException: Table/View 'DERBYDB' does not exist.
>> It would be good if we changed this so the same text is written by
>> both drivers. This reduces the difference seen when changing between
>> client and embedded Derby and it make it possible to reduce the amount
>> of sed-ing or the number of master file variants for some tests.

View raw message