> If PR > 1 is used, we end up with a call to get() raising a > NotFoundExceptionInterface instance if either of the following > conditions is true: > - One of the dependencies of $id does not exist.
PR 1 doesn't bubble out NotFoundException in this case. PR 2 acts like you described, though. On Monday, January 16, 2017 at 6:48:24 PM UTC+3, Matthew Weier O'Phinney wrote: > > On Mon, Jan 16, 2017 at 8:41 AM, Larry Garfield <la...@garfieldtech.com > <javascript:>> wrote: > > On 01/16/2017 04:58 AM, David Négrier wrote: > > > > Ok, we have 3 options, and one day to decide which to choose. > > > > In order to ease the choice, I opened 3 PRs on Github. > > > > I'll ask everyone involved to give feedback on the 3 PRs. > > > > Let me present them briefly. > > > > PR 1: Status Quo: NotFoundExceptionInterface CANNOT bubble up, but we do > not > > standardize MissingDependencyException > > Link: https://github.com/php-fig/fig-standards/pull/870/files > > > > This PR simply improves the current wording. It is easier to understand > but > > is strictly equivalent to PSR-11 as it is today. > > > > > > PR 2: NotFoundExceptionInterface CAN bubble up > > Link: https://github.com/php-fig/fig-standards/pull/869/files > > > > This PR let's NotFoundExceptionInterface bubble up. So a > > `NotFoundExceptionInterface` means either "entry not found" OR "missing > > dependency". The user can make the difference between the 2 using the > `has` > > method. > > > > PR 3: NotFoundExceptionInterface CANNOT bubble up, but we add a > > MissingDependencyException > > Link: https://github.com/php-fig/fig-standards/pull/871/files > > > > This PR adds an explicit MissingDependencyExceptionInterface. > > > > > > Could I ask each of you to have a brief look at these PR and to tell us > how > > you like those? > > Also, for the voting member, please indicate if one of these PRs would > > change your vote from -1 to +1 (or the other way around) > > > > > > Unsurprisingly I'd favor PR 3: Explicit exception. > > > > I'll be honest that I'm still very confused why there's so much > resistance > > from the Editors on using exception types for what they're supposed to > be > > used for. Different error condition, different exception. In 20 years > of > > writing code I cannot recall ever saying "damn, this error message is > too > > precise and specific". I have said the opposite more times than I can > > count. > > > > PR 1 would resolve the awkward wording, although I do feel it is the > > inferior approach as it is less precise and provides less contextual > > information for callers. (That we don't at the moment know when a > caller > > would want that extra information is, IMO, irrelevant as it's so easy to > > provide.) > > > > PR 2 actively works to make using the spec harder, and I cannot get > behind > > that at all. > > > > I am admittedly unlikely to vote +1 on the spec regardless, but should > it > > pass anyway I feel it should still be as good (or least bad) as > possible, > > and that is PR 3. > > From a consumer standpoint, I can see why this would be useful. If PR > 1 is used, we end up with a call to get() raising a > NotFoundExceptionInterface instance if either of the following > conditions is true: > > - The container does not have the "knowledge" necessary to create an > instance of $id. > - One of the dependencies of $id does not exist. > > Being able to differentiate *may* be of use at that point. However, > from experience, if I see a NotFoundExceptionInterface, the only thing > of use to me as a consumer is determining *which* service is missing; > I do not care if it is a *dependency* of another service, just that > it's needed in my object graph, and I didn't provide relevant > information to create it. > > From an implementer's standpoint, PR 3 is a nightmare, as it > *requires* that any attempt to retrieve a dependency is wrapped in a > try/catch block internally. As an example: > > public function get($id) > { > if (isset($this->map[$id])) { > return $this->map[$id]; > } > > try { > $instance = $this->create($id); > return $instance; > } catch (NotFoundExceptionInterface $e) { > throw new MissingDependencyException(sprintf( > 'Could not create "%s" due to a missing dependency', > $id > ), $e->getCode(), $e); > } > } > > Essentially, the try/catch block MUST be present. This is specifying > _internal implementation_, and, of more concern, specifying an > implementation based on try/catch which has significant performance > issues. > > If we go with PR 1, the above can be simplified, based on the needs of > the implementation: > > public function get($id) > { > if (isset($this->map[$id])) { > return $this->map[$id]; > } > > return $this->create($id); > } > > Any NotFoundExceptionInterface raised now bubbles up, and I can see > what is missing and blocking execution. Alternately, my implementation > *could* still wrap in a try/catch block and provide a > MissingDependencyException that acts as a subtype of > NotFoundExceptionInterface; the spec would not disallow it, but also > wouldn't force this implementation detail. > > As such, I'm in favor of option 1. > > -- > Matthew Weier O'Phinney > mweiero...@gmail.com <javascript:> > 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/bf9625dc-6c52-41f5-96d6-e254c7ee8ea9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
