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 Fri, 21 Jul 2006 16:37:53 GMT
Thanks, Knut.

I was unaware that part of the intention was to reduce the number of 
master files.  My patch simply updates existing master files with new 
output.  Are you saying that master files that are currently in 
DerbyNetClient could be removed because the master files in the 
top-level directory are identical?

Perhaps that can be done as a separate patch, as I'm not sure exactly 
what Olav was looking at.

My patch has gotten stale again and I suspect I need to run derbyall 
again.  I'd like to get it in and then maybe we can look at that as a 
second phase.


Knut Anders Hatlen wrote:
> David Van Couvering <David.Vancouvering@Sun.COM> writes:
>> 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?
> Thanks for the explanation, David. I think the change is reasonable. I
> don't have any strong opinion on what's the best message to print, but
> I thought I'd mention that there in fact was something we could do
> about it if you didn't think your solution was optimal. If we can
> avoid subclassing the standard java.sql exceptions, I agree that it is
> a good thing.
> I think Olav filed this issue in order to reduce the number of master
> files. Did you find any canons that could be removed after your
> change?

View raw message