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'm not a big fan of introducing new subclasses of SQLException on an
ad-hoc basis.
Thanks,
-Rick
Myrna
On Thu, Dec 4, 2014 at 1:44 PM, Rick Hillegas <rick.hille...@gmail.com
<mailto:rick.hille...@gmail.com>> wrote:
On 12/4/14 2:26 AM, John English wrote:
On 02/12/2014 00:30, Rick Hillegas wrote:
On 12/1/14 4:08 AM, John English wrote:
However, why not in any case consider deriving a
separate subclass of
SQLException for the duplicate key case? It wouldn't
break any existing code,
it's presumably easy to identify the code sites which
should throw it, and it
would clarify exception handling in some cases.
Hi John,
Note that the SQLException which is thrown is already a
refined subclass of
SQLException. The failed insert will throw a
java.sql.__SQLIntegrityConstraintViolatio__nException. That
may help you code this
approach to the problem.
But wouldn't this also be thrown by other causes such as a check
constraint or foreign key violation? In such cases, an "if"
statement would still be needed to check the actual cause.
Hi John,
Yes, that's true. You're welcome to log an enhancement request for
this behavior.
Regards,
-Rick
