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+unsubscr...@googlegroups.com
<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to php-fig@googlegroups.com
<mailto:php-fig@googlegroups.com>.
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/e78a438b-3852-e841-8000-e971a4b8522f%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
