Hey Krzysiek!
> > 1. ContainerException > > - One interface to represents a runtime and logic exceptions so at the end > we should always base on the implementation. - No clear context. - Enforces > exception implementation. > > I do agree that the fact that the ContainerExceptionInterface can be implemented by both runtime and logic exception makes it very impractical to use. I think everybody here agrees with this point of view (even the proponents for keeping this interface). I you read carefully Matthew's mail, his point is that the exception could be used for some reporting tools (like Zend's Z-Ray or Blackfire). He would like to keep the exception in place for these use cases. > > 2. NotFoundException > > - Not found what? Container was not found? - No clear context. > > The current PSR draft is quite clear: A call to the get method with a non-existing id MUST throw a Psr\Container\Exception\NotFoundExceptionInterface <https://github.com/php-fig/fig-standards/blob/master/proposed/container.md#not-found-exception> . I'm not sure I understand your comment. Do you mean we should rename it to something more specific, like EntryNotFoundExceptionInterface? > > The whole idea to use interfaces with exceptions to mark 'something' is > totally impractical. If we think that something is very important we should > provide the exception classes derived from standard exception hierarchy, > just like we do providing PSR interfaces, because classes are just > interfaces. > > I strongly disagree with you here. Each framework has its own hierarchy of exceptions. Requiring an existing framework to throw an exception provided by this PSR would likely cause breaking changes in the framework. Have a look at Symfony for instance. The container has already a "has" and a "get" method. Implementing PSR-11 would be a breeze (if they want to). If however we require them to use a ContainerException "class" (instead of an interface), that adoption could not be done before Symfony 4 (because Symfony currently has its own NotFoundException and it cannot change it without breaking the API). Best regards, 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+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/cef2ebf6-8d01-4417-98c1-2f8508370644%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
