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 package-level base exception, as
it is a convention we always expect to be available" -- Because PEAR does
it.
* "I would also only type-hint against the PSR exceptions for catches." --
Because we can do Y.
* "having the granularity is nice, and I could potentially see writing
plugins for systems such as Zend's Z-Ray, Blackfire, etc." -- Interesting
point. However, I think it has high cost (boilerplate code, noise in shiny
interfaces, etc.).
* "There are all sorts of unexpected exceptions that an underlying
implementation might throw .. Those should be made consistent between
implementations so that I don't have to worry about those differences." --
No difference with catch (\Exception)
* "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." --
If the point is to have human-friendly message, you can rethrow it with any
another exception class, i.e. no difference with throw new
\RuntimeException('User-friendly message', $e).
I have strong feeling that all these exception madness comes from the fact
that PHP has no concept of checked/unchecked exceptions at language like
Java, C# and others.
It leads to misunderstandings: do we break BC if we would throw exception
like \InvalidArgumentException? Should we declare ContainerException in the
interface? Etc.
If we took into account checked/unchecked separation, we would find out
that most of noisy and technical exceptions are not supposed to be part of
public API (interface).
We wouldn't discuss a lot about "Does \InvalidArgumentException break BC?";
we wouldn't see many technical notes like this one
<https://github.com/php-fig/container/blob/master/src/ContainerInterface.php#L32>
.
Consider NullPointerException from Java.
Does it make sense to rethrow NullPointerException as ContainerException?
Does it OK for you that you'd have bigger trace because of 2 exceptions
(ContainerException + previous)? It makes debugging harder I think, not
easier like someone said above.
Any method can throw NullPointerException. Code must deal with it. It makes
no sense to convert it to ContainerException.
ContainerException doesn't allow you to understand what exactly is wrong
with container.
If you just want to prevent program crash because of it, you'd catch just
\Exception or even \Throwable, no point to catch ContainerException.
ContainerException is unnecessary noise in your shiny interface. Like any
other noise it moves developer away from the domain (DI containers in this
case), it makes him think about unnecessary technical details. It doesn't
help, seriously.
On Sunday, August 21, 2016 at 11:36:05 PM UTC+3, Matthieu Napoli wrote:
>
> 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 PSR-11 any longer because of such a detail,
> so let's go with the majority and move forward!
>
> Matthieu
>
--
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/330b6616-55f5-46ee-b9dd-089488309ffc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
