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 <[EMAIL PROTECTED]> 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?
