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 to catch them. There is no reason to catch an
"unchecked exception" because there is no way the user can provide an
interesting alternative behaviour in the catch statement. So unchecked
exception should essentially always bubble up all the way to the top
of the application and trigger an exception middleware.
For PSR-11, we deemed that the NotFoundExceptionInterface was a
checked exception (because if the container does not contain the entry
you are looking for, the user can maybe try an alternative behaviour
like looking for an alias or creating a default entry).
We also deemed that the DependencyNotFoundExceptionInterface was an
unchecked exception (because it means the container is poorly
configured and there is little to do about it except display an error
message).
Finally, we think that checked exceptions should be part of a PSR
while unchecked exceptions should be out of any PSR (because there is
no need to standardize an exception if you don't need to catch it).
Of course, there is no absolute truth here. We could decide that the
NotFoundExceptionInterface should be "unchecked" (because you can
always call "has" before "get" so there is no reason this exception
should be catched). Also, since it boils down to "what valid use case
can I have to catch a DependencyNotFoundExceptionInterface?", we could
also find a valid use case for catching
DependencyNotFoundExceptionInterface and decide it should be part of
the PSR. But so far, a quick survey of frameworks out there has shown
that no-one ever catches the "dependency not found exceptions".
Also, Larry, you say:
/... 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"
}
/
This is not completely true. The spec states that:
/A call to |get| can trigger additional calls to |get| (to fetch the
dependencies). If one of those dependencies is missing, the
|NotFoundExceptionInterface| triggered by the inner |get| call SHOULD
NOT bubble out. Instead, it should be wrapped in an exception
implementing the |ContainerExceptionInterface| that does not implement
the |NotFoundExceptionInterface|.
/
So your code example is only valid if the container decides not to
follow the recommendation (we used "SHOULD NOT" instead of "MUST NOT"
to cope with existing containers). Of course, we could also strengthen
the wording and write: /If one of those dependencies is missing, the
|NotFoundExceptionInterface| triggered by the inner |get| call MUST
NOT bubble out./
This way, your code sample would be illegal (but it would be harder
for existing containers to implement PSR-11). I have no strong opinion
about the "SHOULD NOT" vs "MUST NOT" idea so far. Your comments are
welcome.
++
David.
See, I would disagree with dependency-not-found being an unchecked
exception. I think that's the fundamental difference. A situation of
"if your child container throws exception X, you're required to catch it
and turn it into anything that's not X but is still Y" seems needlessly
convoluted, but doesn't provide me as a developer sufficient debug
information. I'd potentially want to log differently depending on which
exception it is, but I can't do that if I have no idea what the second
exception is going to be; I just know what it's *not* going to be, which
means I'd need a Pokemon-catch if I wanted to log it. That's what I am
not comfortable with.
I am generally very skeptical about SHOULD, and favor MUST in nearly all
cases by default. SHOULD should be read as "you're allowed to be
incompatible here", which is a statement a spec should make as rarely as
possible.
--Larry Garfield
--
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/285dc4de-8ace-384d-28d9-7a2b855ee898%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
