flush() lacks annotations about throwing UniqueConstraintViolationException exception #6271

New Issue

admin · 2026-01-22T15:29:57+01:00

admin commented

2026-01-22 15:29:57 +01:00

Originally created by @Atulin on GitHub (Jul 24, 2019).

Bug Report

Q	A
BC Break	no
Version	2.6.3

Summary

flush() (or something deeper) lacks annotations about throwing UniqueConstraintViolationException exception, and yet it does throw it when an attempt at adding a duplicate entry is made.

Current behavior

flush() does throw the UniqueConstraintViolationException exception properly, but PHPStorm complains with

How to reproduce

$em = EntityManager::create($conn, $config);
$em->persist($whatever);
try {
    $this->em->flush();
} catch (UniqueConstraintViolationException $e) {
    echo 'Entry already exists';
}

Expected behavior

PHPStorm doesn't complain, I guess ¯\_(ツ)_/¯

Originally created by @Atulin on GitHub (Jul 24, 2019). ### Bug Report  | Q | A |------------ | ------ | BC Break | no | Version | 2.6.3 #### Summary `flush()` (or something deeper) lacks annotations about throwing `UniqueConstraintViolationException` exception, and yet it does throw it when an attempt at adding a duplicate entry is made. #### Current behavior `flush()` does throw the `UniqueConstraintViolationException` exception properly, but PHPStorm complains with ![image](https://user-images.githubusercontent.com/11233299/61821205-f73e8180-ae56-11e9-991e-cc7bf5deb938.png) #### How to reproduce ```php $em = EntityManager::create($conn, $config); $em->persist($whatever); try { $this->em->flush(); } catch (UniqueConstraintViolationException $e) { echo 'Entry already exists'; } ``` #### Expected behavior PHPStorm doesn't complain, I guess ¯\\\_(ツ)_/¯

admin added the Improvement label 2026-01-22 15:29:57 +01:00

admin commented

2026-01-22 15:29:58 +01:00

@SenseException commented on GitHub (Jul 29, 2019):

Thank you for reporting this issue. As far as I understand your issue is less a bug and more a DX one with the entity manager and PHPStorm (and probably other IDEs too). Do you like to create a pull request to improve DX for that?

@SenseException commented on GitHub (Jul 29, 2019): Thank you for reporting this issue. As far as I understand your issue is less a bug and more a DX one with the entity manager and PHPStorm (and probably other IDEs too). Do you like to create a pull request to improve DX for that?

admin commented

2026-01-22 15:29:58 +01:00

@Atulin commented on GitHub (Jul 29, 2019):

I'm not sure what "DX" means in this context. If you could tell me what can be done to fix the issue, I'll try to implement that fix and create a PR, if I'm able to.

@Atulin commented on GitHub (Jul 29, 2019): I'm not sure what "DX" means in this context. If you could tell me what can be done to fix the issue, I'll try to implement that fix and create a PR, if I'm able to.

admin commented

2026-01-22 15:29:59 +01:00

@SenseException commented on GitHub (Aug 1, 2019):

DX is for Developer Experience.

I guess UniqueConstraintViolationException wasn't added as a phpdoc to flush() because it is an exception of DBAL and not ORM.

@Ocramius Should an exception of another library be added as a @throw?

@SenseException commented on GitHub (Aug 1, 2019): DX is for Developer Experience. I guess `UniqueConstraintViolationException` wasn't added as a phpdoc to `flush()` because it is an exception of DBAL and not ORM. @Ocramius Should an exception of another library be added as a `@throw`?

admin commented

2026-01-22 15:29:59 +01:00

@Ocramius commented on GitHub (Aug 1, 2019):

No, I'd say that we should keep documented exceptions to what is clearly thrown by underlying interfaces. Implementations are still capable of throwing exceptions that aren't within the declared set, and those cannot be declared, since anything in the engine can also crash spectacularly (in this language)

@Ocramius commented on GitHub (Aug 1, 2019): No, I'd say that we should keep documented exceptions to what is clearly thrown by underlying interfaces. Implementations are still capable of throwing exceptions that aren't within the declared set, and those cannot be declared, since anything in the engine can also crash spectacularly (in this language)

admin commented

2026-01-22 15:29:59 +01:00

@gbirke commented on GitHub (Feb 28, 2022):

Could you catch and re-throw the DBAL exceptions as an ORMException instead (wrapping the UniqueConstraintViolationException in the previous parameter of the ORMException)? Then the declared exceptions won't need to change and the catching code could still inspect the ORMException (calling getPrevious) to see what happened and recover in some cases.

I've also run into this issue while using PHPStan and will propose a temporary workaround on the doctrine extension until we have a resolution here.

@gbirke commented on GitHub (Feb 28, 2022): Could you catch and re-throw the DBAL exceptions as an `ORMException` instead (wrapping the UniqueConstraintViolationException in the `previous` parameter of the ORMException)? Then the declared exceptions won't need to change and the catching code could still inspect the ORMException (calling `getPrevious`) to see what happened and recover in some cases. I've also run into this issue while using PHPStan and will propose a temporary workaround on the doctrine extension until we have a resolution here.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6271