> Are you suggesting that 2 different exceptions should be present? It seems that MissingDependencyException would mean that the $id service exists but cannot be created since that service depends on another service that is not present.
Exactly. However, as it was discussed in the past, I wouldn't suggest to put MissingDependencyException to the spec. In fact, it can be simple \RuntimeException with proper exception message: as I said above, we read the message in our logs and fix the code/configuration. It also can be more generic MisconfiguredServiceException, like someone suggested previously. It's matter of taste and should be framework-specific I think. But NotFoundException is different story and should be present in the spec with proper meaning. On Tuesday, January 17, 2017 at 7:11:31 PM UTC+3, Chuck Reeves wrote: > > Are you suggesting that 2 different exceptions should be present? It > seems that MissingDependencyException would mean that the $id service > exists but cannot be created since that service depends on another service > that is not present. > > My thoughts go to Zend\Db\Table\Gateway which needs a Zend\Db\Adapter in > order to work. If the Adapter fails to be created a > MissingDependencyException would be thrown in that case > > On Tuesday, January 17, 2017 at 10:56:02 AM UTC-5, Daniel Plainview wrote: >> >> > This change is more in line with >> > existing implementations, and focuses on the primary issue faced by >> > consumers: determining when a service is missing from configuration. >> >> In order to determine it, we look in our logs or at debugging page. We >> read the exception message. >> Different exceptions don't make it any harder I think. We still look at >> the message which may be identical. >> >> That separation was focused on semantic difference. >> Catching NotFoundException is perfectly fine, but I wouldn't expect to >> catch it because of broken service or bad configuration. >> If service is broken, I would expect to see it in my logs. >> >> By the way, "bubbling out" is an inaccurate wording. >> You can make implementation of container so dependencies of service $id >> would never throw NotFoundException, but MissingDependencyException. >> There will be no "bubbling out" at all. >> >> On Tuesday, January 17, 2017 at 6:14:00 PM UTC+3, Matthew Weier O'Phinney >> wrote: >>> >>> We are rebooting the PSR-11 review period again as of now; this marks >>> the third review period, and it will end at 11:59 UTC 29 Jan 2017, >>> with the prospect of holding a vote starting the following day. >>> >>> The only change since the previous review period is a clarification of >>> the role of `NotFoundExceptionInterface`. Previously, the >>> specification stated that calls to `get()` MUST NOT allow such >>> exceptions to bubble out, but must instead convert them to the more >>> generic `ContainerExceptionInterface`. >>> >>> The specification now states that `NotFoundExceptionInterface` >>> instances are allowed to bubble out, and that any call to `get()` >>> where `has()` would return `false` MUST raise a >>> `NotFoundExceptionInterface`. This change is more in line with >>> existing implementations, and focuses on the primary issue faced by >>> consumers: determining when a service is missing from configuration. >>> >>> Please review the specification again at this time, and let us know as >>> soon as >>> possible if you see any remaining problems to address; ideally, please >>> do so in >>> the next 48 hours, so that we may fit within the FIG 2.0 by-law window. >>> >>> -- >>> Matthew Weier O'Phinney >>> mweiero...@gmail.com >>> https://mwop.net/ >>> >> -- 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/8f37e32e-1483-432a-8d5e-0f9ce895875d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
