> but because it doesn't know that it's a child it just throws "I don't
have it", which gets thrown all the way up to the initial caller, who goes
"wait, wat?"
It would be considered as bugged PSR-11 implementation.
> then it needs to wrap that inner Not-Found with... something. That
something should be standardized.
Why?
On Thursday, November 3, 2016 at 6:32:15 PM UTC+3, Larry Garfield wrote:
>
> From moufmouf in that thread:
>
> " The logic behind this is that if a user is calling the get method on
> 'foo' and 'foo' does not exist, it is very different from the user
> calling get on 'foo' and the 'foo' service has a missing dependency. In one
> case, maybe the user screwed up something (i.e. checked exception), in the
> other case, it is the container configuration that is screwed up
> (i.e. unchecked exception)."
>
> They are different error cases. Different error cases should be different
> exceptions. If not, then based on the spec alone (no metadoc, no GitHub
> threads) the following would be legal:
>
> try {
> $c1->get('a');
> } catch (NotFoundExceptionInterface $e) {
> print $e->getMessage();
> // prints "Service 'b' not found"
> }
>
> Because a delegated container didn't have a particular dependency, but
> because it doesn't know that it's a child it just throws "I don't have it",
> which gets thrown all the way up to the initial caller, who goes "wait,
> wat?" If the parent container is going to catch it and handle it, then it
> needs to wrap that inner Not-Found with... something. That something
> should be standardized.
>
> If I as the caller don't care which type of exception is thrown, well,
> that's where interfaces that cover both exceptions are helpful. :-)
>
> --Larry Garfield
>
> On 11/03/2016 03:53 AM, David Négrier wrote:
>
> @Larry: the DependencyNotFoundException was discussed quite recently.
>
> Here is the relevant link explaining the story behind it and why there is
> no DependencyNotFoundException:
> https://github.com/php-fig/fig-standards/pull/810
>
>
> Le mercredi 2 novembre 2016 22:53:13 UTC+1, Matthieu Napoli a écrit :
>>
>> Splitting off the main review thread, quoting Larry:
>>
>> > 1) What other exceptions might get($id) throw besides
>> NotFoundException?
>>
>> \Exception (because any exception could be thrown when creating services)
>> => are you suggesting we should document it in the standard?
>>
>> > 2) I would much prefer to see a DependencyNotFoundException defined for
>> that case than leaving that up to individual implementers. Standard
>> error handling is just as important if not moreso than the happy path.
>>
>> Why/when would one want to catch that exception (use case)? This is not a
>> need we have seen when using container-interop as of now, I'm of course not
>> against adding new stuff but we should do it for a reason.
>>
>> Matthieu
>>
> --
> 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/c341150d-2834-42ba-a7ac-058510f4cb7c%40googlegroups.com
>
> <https://groups.google.com/d/msgid/php-fig/c341150d-2834-42ba-a7ac-058510f4cb7c%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/ade5a821-e32a-45bb-995d-18564974bbcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
