Open hansbogert opened 5 years ago
Documenting all @throws
is not possible here, since there are multiple un-checked exception types upstream from that interface (in implementations).
You can gladly suggest those that are directly thrown in the EntityManager
(implementation).
Well if you mean by unchecked exceptions, runtime exceptions, then I totally agree.
So basically we'd want to add
/**
* @throws \Doctrine\ORM\OptimisticLockException If a version check on an entity that
* makes use of optimistic locking fails.
* @throws ORMException
* @throws UniqueConstraintViolationException
*/
right?
Something like that, but please look at the current 3.x work.
We're doing some housekeeping on the 3.0.0 milestone. Since nobody seems to be actively working on this topic I'm removing this PR from the 3.0.0 milestone.
That being said, the issue does not really look actionable at the moment. I'd be happy to discuss and merge any PR adding reasonable @throws
annotations though. Also, if we take this topic seriously, we should think about some kind of tooling that tells us about correctness and completenes of such annotations.
@morozov mentioned https://phpstan.org/blog/bring-your-exceptions-under-control in https://github.com/doctrine/dbal/pull/5777, we might want to look into it.
Bug Report
Summary
Interfaces of, e.g.,
EntityManagerInterface
do not include@throw
annotations.Current behavior
This causes IDEs to not notice that for example calls to
EntityManagerInterface::flush
may cause exceptions.How to reproduce
Reference
EntityManagerInterface
in an IDE like PhpStorm or other, and have the following snippetExpected behavior
I expect the IDE to be able to tell, based on docblocks of the Doctrine library, that we should catch, (or re-throw) the exceptions which can occur.