Re: [PSR-11] Remove ContainerException

W dniu poniedziałek, 29 sierpnia 2016 15:24:56 UTC+2 użytkownik David Négrier napisał: > > Do you mean we should rename it to something more specific, like > EntryNotFoundExceptionInterface? > > Yes, I do. > I strongly disagree with you here. Each framework has its own hierarchy of >

Re: [PSR-11] Remove ContainerException

W dniu poniedziałek, 29 sierpnia 2016 15:24:56 UTC+2 użytkownik David Négrier napisał: > > > I'm not sure I understand your comment. Do you mean we should rename it to > something more specific, like EntryNotFoundExceptionInterface? > Yes, I do. > I strongly disagree with you here. Each

Re: [PSR-11] Remove ContainerException

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

Re: [PSR-11] Remove ContainerException

W dniu poniedziałek, 15 sierpnia 2016 21:10:07 UTC+2 użytkownik Matthieu Napoli napisał: > > Hi, > PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get > that PSR moving! > Here is a change I would like to suggest: *remove the interface > ContainerException*. > Hello,

Re: [PSR-11] Remove ContainerException

This conversion (like some others in this group) looks like the following: — Why do we need X? — Because we can do Y with it! — Are you sure that Y is a good thing? — *no answer*. — OK, let's keep X. Just for clarity, arguments for this exception are: * "PEAR most definitely wants to keep the

Re: [PSR-11] Remove ContainerException

Hi all, thanks for participating in this discussion. While David and I feel the same, it seems we are alone. We do not see real usage (not implementations or "what ifs" but actual usage) of that interface today (see https://github.com/php-fig/container/pull/2). However its not worth blocking

Re: [PSR-11] Remove ContainerException

Hey there Matthieu, As a consumer of a PSR-implementing library, not only would I only type-hint against the PSR interfaces rather than the library's elements, I would also only type-hint against the PSR exceptions for catches. Unless my consumer code's catch is specifically able to deal with

Re: [PSR-11] Remove ContainerException

Hey Chuck, PEAR FAQ says: > By implementing the base package exception interface, all exceptions for a given pear package can be caught with catch (\PEAR2\PackageName\Exception $e). But in PSR-11, there is only one (useful) exception interface: NotFoundException. Aknowledging the fact there is

Re: [PSR-11] Remove ContainerException

Hi Chuck, Are you using ContainerInterface or do you plan to use it in PEAR? If so, in which scenario would that exception be useful? The goal is to collect such scenarios to see if that specific interface serves any purpose. You are welcome of course to create a base exception class (or

Re: [PSR-11] Remove ContainerException

> On Aug 15, 2016, at 14:10, Matthieu Napoli wrote: > > Hi, > > PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get > that PSR moving! Woohoo! > Here is a change I would like to suggest: remove the interface > ContainerException. ... > After

Re: [PSR-11] Remove ContainerException

On 8/15/16 13:13, Glenn Eggleton wrote: I believe removal of it is going to cause a lot of BC Breaks... They can't have BC breaks on something that is not standardized yet. PSR-11 is still a work in progress as far as I know. For example in Slim we do extend from *ContainerException* * *

Re: [PSR-11] Remove ContainerException

I believe removal of it is going to cause a lot of BC Breaks... For example in Slim we do extend from *ContainerException* [1]: https://github.com/slimphp/Slim/blob/3.x/Slim/Exception/ContainerException.php We do actually use it.

[PSR-11] Remove ContainerException

Hi, PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get that PSR moving! Here is a change I would like to suggest: *remove the interface ContainerException*. After years of using container-interop and ContainerInterface I have not seen a use case for that exception. We