On Wed, Aug 17, 2016 at 3:07 AM, David Négrier <david.negr...@gmail.com> wrote:
> I understand Paul's idea to have a package-specific base exception, but
> nothing prevents implementing package to have their own base exception.
> Since this PSR contains only 1 useful exception (NotFoundException), it
> might not make a lot of sense to keep an additional "base exception".
In zend-servicemanager, we've setup our package ExceptionInterface to
extend ContainerException, and have several additional exceptions that
we trigger other than "not found" conditions:
- ContainerModificationsNotAllowed. By default, the SM is setup to not
allow changes to services already defined, and this exception is
raised when attempts are made to do so.
- CyclicAlias. We have cyclic detection algorithms, and this exception
is triggered when one is detected. This is actually *very* useful when
putting together an application made of many libraries.
- InvalidService. In addition to a normal application-level DI
container, we also provide context-specific locators for plugins.
These provide algorithms internally to ensure that the plugin instance
is valid for the context (usually this means it implements a given
interface); we trigger this exception when it is not.
- ServiceNotCreated. This is different than "not found"; usually it
means that a dependency or pre-condition was not met, and the
container could not create the service.
While I rarely see code that *catches* container exceptions, having
the granularity is nice, and I could potentially see writing plugins
for systems such as Zend's Z-Ray, Blackfire, etc., that could provide
reporting based on caught container exceptions:
switch (true) {
case ($exception instanceof \Interop\Container\ContainerException):
// report container exception details,
// which might include introspection for available
// service definitions
break;
case ($exception instanceof \Psr\Log\InvalidArgumentException):
// report psr-3 exceptions
break;
case ($exception instanceof \Zend\Mvc\Exception\ExceptionInterface):
// report zend-mvc exceptions
// etc.
break;
}
As such, I'm a proponent of keeping the base exception interface.
<snip>
> On a side note, regarding migration from container-interop to PSR-11, we
> will probably deprecate container-interop in favor of PSR-11 when it's
> ready. It the PSR-11 Container interface stays the same, it will be
> "compatible" with container-interop's ContainerInterface. We could therefore
> publish a version 1.1 of container-interop's ContainerInterface that simply
> extends PSR-11's ContainerInterface. That would "automagically" migrate all
> container-interop projects to PSR-11. This is of course assuming that there
> is no BC breaks between container-interop and PSR-11.
We did this with zend-servicemanager, too — our own
ServiceLocatorInterface was compatible with container-interop, so we
modified ours to extend the container-interop interface; users were
then immediately able to use our package anywhere container-interop
was expected, with no BC breaks.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
--
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/CAJp_myUXtyFK0j1cQsYMxd3E3cXxMyc4UOhD2iROm%2B1ZZRaj4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
