Hi people!
This issue has been standing for the last 2 weeks with no activity.
Let's revive this and try to close it.
There is currently one PR made by Larry
(https://github.com/php-fig/fig-standards/pull/844) proposing to add a
"MisconfiguredServiceExceptionInterface" to PSR-11. There is
> This way I can catch all container exceptions using
> ContainerException, or the individual exception I am interested in. In
> your example, it would not be possible to catch only exceptions raised
> by the container, as other Exceptions could be raised (if for example
> pulling service config
I deliberately picked a vague term, as I see it we have 3 exceptions:
ContainerException
NotFoundException extends ContainerException
CreationException extends ContainerException
Names are not finalised.
This way I can catch all container exceptions using ContainerException, or
the individual
> because create errors should be handled differently from service not
being found
Sure. We already can do it:
try {
$this->container->get('foo');
} catch (NotFoundService $e) {
// ...
} catch (\Exception $e) {
// Configuration syntax error, circular dependencies, etc.
}
Why do you
> These are different errors and could/should be handled differently.
I think we all agree on this point. The question is do you need
explicit CreationException and why?
On Wednesday, November 23, 2016 at 2:08:40 PM UTC+3, GeeH wrote:
>
> My opinion is this:
>
> NotFoundException - we don't
My opinion is this:
NotFoundException - we don't have a service for this key, you've messed up
your configuration somewhere
CreationException - argh, something went wrong creating your service, this
is probably a bug or coding problem
These are different errors and could/should be handled
@Larry
> Those would imply different people are doing something wrong, so it's a
different person's responsibility to fix.
It is already clear. If it is not NotFoundServiceException, then it is not
user's fault. No need to have yet another exception.
So we return to the same question: what's
>
> https://github.com/php-fig/fig-standards/pull/844
>
> As far as use case, beyond the semantic distinction "missing" implies the
> caller is doing something wrong. "Broken" means the configuration is
> wrong. (Even if the configuration in this case is a hard-coded class, it's
> still
We discussed the exception handling at the php[world] meeting, and the
general consensus from those in the room was that semantically
"missing", "broken", and "other" are distinct error conditions that
should be treated separately. To that end I offer the following PR so
there's something
> So why even mention it then?
I think it's because most implementations are not aware of this difference,
but it's important.
It doesn't automatically mean that the interface must reflect the
DependencyNotFoundException.
@throws FooException means "it's your possible issue, take care of it".
The major problem with unchecked exceptions is that it is not class
consumer business.
What do you say when someone throws SomethingIsBrokenInsideOfMe to you? I'd
say "hey, take a vacation, fix yourself, you look unhealthy". Is it not my
business what exactly is broken (leg or arm, whatever, it
On 11/04/2016 06:27 AM, David Négrier wrote:
I'll try an analogy with Java.
In Java, there is a difference between checked and unchecked
exceptions. Checked exceptions are the exceptions that should be
catched by the user. Unchecked exceptions are the exceptions for which
it makes no sense
I'll try an analogy with Java.
In Java, there is a difference between checked and unchecked exceptions.
Checked exceptions are the exceptions that should be catched by the user.
Unchecked exceptions are the exceptions for which it makes no sense to
catch them. There is no reason to catch an
> 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
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.
@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
If you need to know whether dependency of a service is missing and you have
some special logic behind it... What about
DependencyArgumentTypeMismatchException, MissingRequiredArgumentException
and tons of others container-is-screwed exceptions? What makes them less
important?
(question to
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
18 matches
Mail list logo
