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? -- Knut Anders
