This is the logic we had for PSR-6, as well. There are all sorts of
unexpected exceptions that an underlying implementation might throw,
perhaps even indirectly via another backend. Those should be made
consistent between implementations so that I don't have to worry about
those differences.
A spec is as much about the failure cases as the success cases.
Recall also that PHP has the ability to nest exceptions, so it's
entirely reasonable to expect an underlying implementation to do
something like:
catch (\Exception $e) {
throw new ContainerException($e->getMessage(), $e->getCode(), $e);
}
Which would give us a catchable ContainerException, with a
human-friendly message/code, and access to the underlying
implementation-specific exception as well if appropriate for debugging.
PEAR got this one right, IMO, and it's worth emulating. I'd favor
keeping the common exception, although it is better as an interface than
a base class.
--Larry Garfield
On 08/17/2016 07:02 AM, Chuck Burgess wrote:
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 one specific PSR exception (e.g. NotFoundException), then I would
generally only catch against the library's base exception, thus able
to generically contain the scenario of the library itself throwing
whatever it might throw. In this case, I understand the feeling that
having only one (specific) exception can make a base exception seem
unnecessary. However, I think keeping it not only allows for the
convention/expectation that consumers may already have... it also
future-proofs my consumer code for when this PSR is BC-superceded and
adds more exceptions.
A less prevalent case might be the implementing library having its own
larger set of exceptions, where it won't necessarily make sense for
them all to extend/implement the one NotFoundException. The worse
alternative there would be for the library have and throw its own...
now my consumer code has to know about them rather than staying only
PSR-aware. If the base exception is available, the library can
extend/implement from it, and thus all library-added exceptions can be
caught by catching the PSR base exception alone.
CRB
On Aug 17, 2016 6:30 AM, "Matthieu Napoli" <matth...@mnapoli.fr
<mailto:matth...@mnapoli.fr>> wrote:
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
interface) in PEAR's container package to satisfy your internal
conventions.
Matthieu
Le Mer 17 août 2016, à 12:57, Chuck Burgess a écrit :
PEAR most definitely wants to keep the package-level base
exception, as it is a convention we always expect to be
available. We have *required* this for years, originally as a
class in PEAR1 standards, until we came up with the idea of it
instead being an interface while working on the PEAR2 standards.
We were quite happy with its demonstrated benefits, which proved
even better as an interface than a class [1], and were tickled to
see the use of it spread into the community after we published it.
We would prefer to *not* lose the base exception interface
requirement.
CRB
[1] -- https://wiki.php.net/pear/rfc/pear2_exception_policy
<https://wiki.php.net/pear/rfc/pear2_exception_policy>
On Aug 15, 2016 7:35 PM, "Paul Jones" <pmjone...@gmail.com
<mailto:pmjone...@gmail.com>> wrote:
> On Aug 15, 2016, at 14:10, Matthieu Napoli
<matth...@mnapoli.fr <mailto:matth...@mnapoli.fr>> 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 years of using container-interop and
ContainerInterface I have not seen a use case for that
exception. We initially added it to represent any exception
that could happen in a container.
On principle alone, I usually like to see a package-specific
base exception class, so that you can catch any/every
exception from a particular package. (Maybe that's more an
unnecessary consistency on my part.)
--
Paul M. Jones
http://paul-m-jones.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+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/8473e5cb-1d9f-b757-21d7-7aa86ed3b180%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
