db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camilla Haase <camilla.ha...@oracle.com>
Subject Re: Fwd: Duplicate key feature request
Date Fri, 05 Dec 2014 14:38:55 GMT
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?
>
> Myrna
>
>
> On Thu, Dec 4, 2014 at 1:44 PM, Rick Hillegas <rick.hillegas@gmail.com
> <mailto:rick.hillegas@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
>
>

Mime
View raw message