> Different error condition, different exception. In 20 years of writing code I cannot recall ever saying "damn, this error message is too precise and specific".
@Larry nobody says the opposite, we all agree on this one. Of course, it must be different exception with nice and precise class name and descriptive exception message (we want to have straightforward messages in our error log, but in case of logging, we catch *all* exceptions). We just say that it's out of the spec. Just like CircularDependencyException. There is no this exception in the spec. And I really don't see why you make MissingDependencyException more special over CircularDependencyException. They are both very important, but they don't bring value in this context. P.S. I really don't want to offend anyone, I'm just very curious to understand opinions on this topic. On Monday, January 16, 2017 at 5:41:23 PM UTC+3, Larry Garfield wrote: > > On 01/16/2017 04:58 AM, David Négrier wrote: > > Ok, we have 3 options, and one day to decide which to choose. > > In order to ease the choice, I opened 3 PRs on Github. > > I'll ask everyone involved to give feedback on the 3 PRs. > > Let me present them briefly. > > *PR 1: Status Quo: NotFoundExceptionInterface CANNOT bubble up, but we do > not standardize MissingDependencyException* > Link: https://github.com/php-fig/fig-standards/pull/870/files > > This PR simply improves the current wording. It is easier to understand > but is strictly equivalent to PSR-11 as it is today. > > > *PR 2: NotFoundExceptionInterface CAN bubble up* > Link: https://github.com/php-fig/fig-standards/pull/869/files > > This PR let's NotFoundExceptionInterface bubble up. So a > `NotFoundExceptionInterface` means either "entry not found" OR "missing > dependency". The user can make the difference between the 2 using the `has` > method. > > *PR 3: NotFoundExceptionInterface CANNOT bubble up, but we add a > MissingDependencyException* > Link: https://github.com/php-fig/fig-standards/pull/871/files > > This PR adds an explicit MissingDependencyExceptionInterface. > > > Could I ask each of you to have a brief look at these PR and to tell us > how you like those? > Also, for the voting member, please indicate* if one of these PRs would > change your vote* from -1 to +1 (or the other way around) > > > Unsurprisingly I'd favor PR 3: Explicit exception. > > I'll be honest that I'm still very confused why there's so much resistance > from the Editors on using exception types for what they're supposed to be > used for. Different error condition, different exception. In 20 years of > writing code I cannot recall ever saying "damn, this error message is too > precise and specific". I have said the opposite more times than I can > count. > > PR 1 would resolve the awkward wording, although I do feel it is the > inferior approach as it is less precise and provides less contextual > information for callers. (That we don't at the moment know when a caller > would want that extra information is, IMO, irrelevant as it's so easy to > provide.) > > PR 2 actively works to make using the spec harder, and I cannot get behind > that at all. > > I am admittedly unlikely to vote +1 on the spec regardless, but should it > pass anyway I feel it should still be as good (or least bad) as possible, > and that is PR 3. > > --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/19c6ff6b-cd20-4af6-b609-a362add4e58a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
