In https://github.com/neos/typo3cr-search/pull/26/files/9369b8a6d6107a461c884abed7f17f4892ed6dbb#r163656917 @daniellienert opposed my move of adding
@throws to a method, because the exception is thrown in a called method, not the method itself.
I dare to oppose, for two reasons:
- If some PHP method throws an exception, and we do not catch it, I think we should (and actually do?) add
- I started to add them also when it’s an “indirect throw”, and found it quite helpful. Because it tells you, that there is no error handling inside, and you should maybe add some.
Since we do not have anything related in the CGL, I wanted to get some input. Basically I see three options:
- A: we only add
@throwsfor thise exception thrown in the method directly, using
- B: we always add any exception that the method may emit, because it’s not caught
- C: we leave it open to the developer’s preference
My gut feeling would be C would be the most viable option, since it allows us to add those annotations, but does not force us to eventually adjust the whole codebase. This isn’t a PSR-2-style kinf of change, after all.
PS: Daniel mentioned the risk of those annotations becoming outdated if the called method changes and no longer throws an exception. I agree that this can happen, but imagine instead of
@throws you’d need to adjust a try/catch block. Same story, yet noone would oppose adding try/catch for that reason. On the contrary, exactly because my IDE warns me about both cases, this is manageable today, more than it ever was.