db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Fwd: Duplicate key feature request
Date Thu, 04 Dec 2014 22:55:43 GMT
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>
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.SQLIntegrityConstraintViolationException. 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