On Mon, Jan 16, 2017 at 8:41 AM, Larry Garfield <la...@garfieldtech.com> 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
mweierophin...@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/CAJp_myUwZ6WFVPSGQuBvAR%3DGrocVpsVVdai%2BCuhTx5BZiJyy1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
