Rick Hillegas <[email protected]> writes: > On 12/5/14 6:38 AM, Camilla Haase wrote: >> I think these subclasses are not specific to Derby but are found in >> the Java SE API package java.sql. >> >> Kim >> >> On 12/4/2014 5:55 PM, Myrna van Lunteren wrote: >>> Moving this discussion to derby-dev... >>> >>> Forgive my ignorance in this area... >>> >>> I had a look at the Derby source code and we do not currently seem to >>> have any subclasses of SQLException, except SQLExceptionWrapper. >>> >>> (There are some client exceptions that extend SqlException, but that one >>> extends Exception, not SQLException). >>> >>> I wonder why this was not done before - presumably there was no need >>> before? Are there negatives connected to extending >>> java.sql.SQLException? Does anyone have insights on this? > The JDBC spec requires drivers to return the refined subclasses of > java.sql.SQLException which were introduced in Java 6. I don't think > we are forbidden to further refine those subclasses. But we would want > to verify that. > > Before doing this, I would want us to agree on a model for how far > this refinement goes. I assume that we don't want to introduce a > separate subclass for each possible SQLState. The SQLStates are > organized into families, identified by the leading two digits of the > SQLStates. We could introduce a separate subclass for each of those > families, but that would still be a lot of subclasses and it wouldn't > solve John's problem.
I think we would also need to find a solution to the old problem with sharing classes between the client and the engine. We wouldn't want to end up with a solution where one would have to check for one exception class if one is using the embedded driver, and another class if one is using the client driver. -- Knut Anders
