Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[PSR-7] @throws annotations #345

Merged
merged 1 commit into from
Oct 16, 2014

Conversation

weierophinney
Copy link
Contributor

  • Added @throws annotations for all setters or methods accepting arguments that must be validated by implementors. In each case, InvalidArgumentException is specified.
  • Made @params/@return/@throws order consistent, and removed empty lines between any such annotations for further consistency.
  • Moved @link annotations before @params in all cases.

Based on a mailing list thread.

@weierophinney weierophinney force-pushed the hotfix/invalid-arguments branch from edcb2eb to b4657ed Compare October 13, 2014 15:33
@Crell
Copy link
Contributor

Crell commented Oct 14, 2014

(thumbsup). Although I hate to point out that PSR-3 and PSR-6 DO define their own exceptions in their own namespace rather than using the SPL exception directly. So this would be inconsistent.

Edit: OK, really GitHub, what is the emoticon? Why must you make things difficult?

@weierophinney
Copy link
Contributor Author

@Crell Interestingly, PSR-3 makes reference to a Psr\Log\InvalidArgumentException in the narrative, but does not actually define it, nor reference it in the interfaces in the specification document. The actual code in psr/log, however, does define one -- but it simply extends InvalidArgumentException.

And PSR-6 is still far from completion, so it's hard to say what will happen there with exceptions... meaning that this proposal has the possibility of helping set the standard.

In ZF2, we took the following approach: each component defines an exception marker interface, and then any component-specific exceptions implement that, while extending an appropriate SPL exception type. This gives the ability to:

  • catch the specific exception type
  • catch any component exceptions
  • catch the more general SPL exception type
  • catch the global Exception type

In other words, ultimate granularity.

So: my question is: should I propose a component exception marker interface as part of the proposal? Or leave it entirely to the implementor? (I'm leaning towards the latter, as there's already a lot of hubbub on the list about proposals getting too complex.)

@philsturgeon
Copy link
Contributor

Conflicts ahoy. I had a look but they're a bit of a bugger. Can you sort em out?

@weierophinney
Copy link
Contributor Author

@philsturgeon will do, and will ping when it's fixed.

@weierophinney weierophinney force-pushed the hotfix/invalid-arguments branch from b4657ed to 3f0609a Compare October 16, 2014 16:51
- Added `@throws` annotations for all setters or methods accepting arguments
  that must be validated by implementors. In each case,
  `InvalidArgumentException` is specified.
- Made `@params`/`@return`/`@throws` order consistent, and removed empty lines
  between any such annotations for further consistency.
- Moved `@link` annotations before `@params` in all cases.
@weierophinney weierophinney force-pushed the hotfix/invalid-arguments branch from 3f0609a to bb55dce Compare October 16, 2014 16:52
@weierophinney
Copy link
Contributor Author

@philsturgeon All conflicts fixed. :)

philsturgeon added a commit that referenced this pull request Oct 16, 2014
@philsturgeon philsturgeon merged commit 100f848 into php-fig:master Oct 16, 2014
@weierophinney weierophinney deleted the hotfix/invalid-arguments branch October 17, 2014 13:00
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants