> My main issue is that the current text says "In situation A, do X. In
situation B, do any capital letter that is not A." That is a construction
I simply cannot get behind in any specification of any sort, as it is
simply too vague and begs for inconsistent error handling
There is no such situation like B from consumer point of view, thus you
don't need to describe what to do in this case.
You can rephrase text, e.g. "Throw NotFoundException when and only when the
requested service is not found",
and define what "requested service" is.
Probably, it makes sense to add example of right and wrong pseudo
implementations to the spec.
On Saturday, January 14, 2017 at 11:46:51 PM UTC+3, Larry Garfield wrote:
>
> On 01/14/2017 11:37 AM, David Négrier wrote:
>
> *snip*
>
> So my code was looking like this:
>
> try {
> $service = $container->get($id);
> } catch (NotFoundExceptionInterface $e) {
> if ($id === $e->getMissingIdentifier()) {
> // Display an error message to the user saying the service does
> not exist
> } else {
> // Oops, I should not have caught that in the first place, I don't
> know what to do with this, let's rethrow this.
> throw $e;
> }
> }
>
> When someone catches the "NotFoundException", the "if" statement inside
> the "catch" was almost systematic.
>
> This is because we actually have 2 different exceptions. One is "the user
> provided an invalid identifier", and the other is: "the container
> configuration somewhere has an error, with probably an invalid identifier
> stored".
>
> So we decided that those 2 exception cases should be treated differently.
>
>
> I agree entirely on this point! These are two separate error conditions,
> and thus should have 2 separate exceptions.
>
>
> By restricting the scope of the NotFoundExceptionInterface to the first
> outermost `get` call, one user can write:
>
> try {
> $service = $container->get($id);
> } catch (NotFoundExceptionInterface $e) {
> // Display an error message to the user saying the service does not
> exist
> // No need to bother checking that the caught exceptions relate to
> $id, this is sure.
> }
>
> Now, I understand this can be discussed in many ways.
>
> For instance, one could argue that my example is buggy, because I'm using
> exceptions for control flow. If I'm dealing with user input, I should first
> use "has" (and therefore, I'm sure the entry does exist, so if a
> "XxxNotFoundException" is triggered, it has to be a "missing dependency
> exception".
>
> I don't think there is "one and only one" truth regarding the definition
> of exceptions. It really depends on where one puts the cursor, and the FIG
> has never defined clearly which exceptions should be part of a PSR and
> which should be out of it.
>
>
> My "cursor" is that defining what code should do on the not-happy path is
> at least as important if not moreso than what happens on the happy path,
> especially for standards. The history of HTML and CSS should have seared
> that into our brains by now. :-)
>
> (Most of the incompatibility of different HTML engines in the bad old days
> wasn't in how they handled perfect markup but in how they handled the
> million ways in which markup could be broken. The HTML5 spec is so
> enormous precisely because it tries to retcon the many different ways of
> handling invalid code into a coherent standard.)
>
> My main issue is that the current text says "In situation A, do X. In
> situation B, do any capital letter that is not A." That is a construction
> I simply cannot get behind in any specification of any sort, as it is
> simply too vague and begs for inconsistent error handling. (Eg, every
> browser handling a missing </div> tag differently.)
>
> I have offered two alternatives that would be acceptable: In situation B,
> throw MisconfiguredServiceException or MissingDependencyException. Either
> one would resolve the issue with the spec's error handling. (Based on
> earlier discussion I agree that MissingDependency is more specific and thus
> a better approach.) If neither of those are acceptable to you, please
> offer your own alternative that resolves the incomplete error handling.
>
> --Larry Garfield
>
--
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/e1922c92-566b-4981-96f5-56ba99557c68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
