On Tuesday, July 26, 2016 at 4:01:17 PM UTC-7, Larry Garfield wrote: > > From http://www.php-fig.org/psr/psr-6/#error-handling > > " For that reason Implementing Libraries MUST NOT throw exceptions other > than those defined by the interface" > > The spec explicitly says not to throw exceptions except where explicitly > specified. We can't recommend throwing an extra exception then without it > being a BC break in the specification, which would affect potentially all > current users of it. (There are multiple PSR-6 implementations already in > the wild, and no doubt projects using them.) > > Whatever the arguments for an exception may be, I don't think we can > consider them without a BC break. >
Re: BC break Is this a really big problem? The changes in PSRs doesn't immediately change libraries in the wild. The psr-6 libraries can still provide another major version, so that the users of those libraries can keep the old behavior with the old stables. Actually there are some libraries already throwing InivalidArgumentException: https://github.com/tedious/Stash/blob/master/src/Stash/Item.php#L365 https://github.com/symfony/cache/blob/master/CacheItem.php#L75 Of course yours is using assertion: https://github.com/php-fig/cache-util/blob/master/src/BasicCacheItemTrait.php#L69 If we decide on either of assertion or exception, there will be certainly BC breaks in either side, and you can not avoid them :( If you can not avoid them, let's think this way; it is just a good chance to learn how to change PSRs :) Another small benefit of throwing exception is that, it will allow libraries to notify users when it is invalid (for example past date). `CacheItemInterface::expiresAt()` returns the object, so there is no reliable way to notify such errors to users (warnings can be easily neglected, you know?). Someone unintentionally passes a past date and the value will never be cached, then they might keep banging their heads for hours. -- Takashi Matsuo > > --Larry Garfield > > > On 07/26/2016 04:30 PM, Daniel Plainview wrote: > > > Throwing `\InvalidArgumentException` is > > another widely used alternative, however, that would be a change in the > > specification (as Calling Libraries would then need to know to catch that > > exception as well). > > Let me disagree. Why Calling Libraries have to know about it? Why Calling > Libraries don't have to know about AssertionError exception then? > > PHP is annoying in this part: it doesn't distinguish between checked and > unchecked exceptions at language level > like Java does. > However, it doesn't mean that we have to treat all exceptions as checked > ones. > Who said that \InvalidArgumentException or, let's say, \LogicException > must be documented? > > These exceptions are very close to runtime exceptions in Java: > https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html > And runtime exceptions include, for example, IllegalArgumentException. > These exceptions notify about errors, this is not public contract of an > interface. > You usually don't need to catch them directly. They just should be fixed > at the code level. Or infrastructure level. > > (Moreover, in my opinion, \LogicException is something that close to > compile errors in Java, not even runtime exceptions, because it includes > http://php.net/manual/en/class.badmethodcallexception.php). > > On Tuesday, July 26, 2016 at 10:46:53 PM UTC+3, Larry Garfield wrote: >> >> Hi folks. Based an a recent discussion with someone writing a PSR-6 >> implementation, I would like to offer the following errata for PSR-6: >> >> https://github.com/php-fig/fig-standards/pull/787 >> >> I think the text of it is rather self-explanatory, and I link to the >> original GitHub discussion that spawned the question. >> >> Comments/feedback/etc. welcome. As it's a non-trivial change (although >> not API changing) it would probably need a vote, but likely an >> uncontroversial one. >> >> --Larry Garfield >> > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to php-fig+u...@googlegroups.com <javascript:>. > To post to this group, send email to php...@googlegroups.com <javascript:> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/8a897f5c-41b1-436e-95ed-38397cfccead%40googlegroups.com > > <https://groups.google.com/d/msgid/php-fig/8a897f5c-41b1-436e-95ed-38397cfccead%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f78219db-f1c6-4aba-80a2-ae67e634b2c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
