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.
David
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?
>
|