--
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.
To post to this group, send email to php...@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.
For more options, visit https://groups.google.com/d/optout.
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
.NotFoundExceptionInterface
triggered by the
inner get
call MUST NOT bubble out.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 toget
can trigger additional calls toget
(to fetch the dependencies). If one of those dependencies is missing, theNotFoundExceptionInterface
triggered by the innerget
call SHOULD NOT bubble out. Instead, it should be wrapped in an exception implementing theContainerExceptionInterface
that does not implement theNotFoundExceptionInterface
.
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, theNotFoundExceptionInterface
triggered by the innerget
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.
--
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.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ee9ba0c8-c4a4-480f-ac9b-d434f7ba64e4%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/2pnhudRUpQg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a3502dd2-6319-4072-9c09-0c42af509c71%40googlegroups.com.
--
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.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a3502dd2-6319-4072-9c09-0c42af509c71%40googlegroups.com.
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 configuration so it's in-scope for PSR-11, not PSR-11-followup.) Those would imply different people are doing something wrong, so it's a different person's responsibility to fix.
try {
$this->container->get('foo');
} catch (NotFoundService $e) {
// ...
} catch (\Exception $e) {
// Configuration syntax error, circular dependencies, etc.
}
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 from database or memory, or using an HTTP request, these services may raise uncaught exceptions).
Personally, I would handle missing services differently to a general container error and would be keen to see the spec reflect this