Re: [PSR-11] Exceptions
> This way I can catch all container exceptions using > ContainerException, or the individual exception I am interested in. In > your example, it would not be possible to catch only exceptions raised > by the container, as other Exceptions could be raised (if for example > pulling service config from database or memory, or using an HTTP > request, these services may raise uncaught exceptions). Again, can we get an actual use case where one would need to catch MisconfiguredException (or whatever the name) separately from \Exception? We still have had no answer to that. > Personally, I would handle missing services differently to a general > container error and would be keen to see the spec reflect this NotFoundException is already a thing in the spec, do you have something else in mind? -- 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/1479920713.146140.797206121.5D4CB9FE%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSR-11] Exceptions
I deliberately picked a vague term, as I see it we have 3 exceptions:
ContainerException
NotFoundException extends ContainerException
CreationException extends ContainerException
Names are not finalised.
This way I can catch all container exceptions using ContainerException, or
the individual exception I am interested in. In your example, it would not
be possible to catch only exceptions raised by the container, as other
Exceptions could be raised (if for example pulling service config from
database or memory, or using an HTTP request, these services may raise
uncaught exceptions).
Personally, I would handle missing services differently to a general
container error and would be keen to see the spec reflect this, however, at
this point I don't really feel strongly enough to spend any more time
discussing.
G
On Wednesday, 23 November 2016 15:29:05 UTC, Daniel Plainview wrote:
>
> > because create errors should be handled differently from service not
> being found
>
> Sure. We already can do it:
>
> try {
> $this->container->get('foo');
> } catch (NotFoundService $e) {
> // ...
> } catch (\Exception $e) {
> // Configuration syntax error, circular dependencies, etc.
> }
>
> Why do you need CreationException, can you provide some use cases when you
> want to catch exactly this exception?
>
> By the way, I don't know if you did it on purpose, but your name
> (CreationException) seems more vague than Larry's
> MisconfiguredServiceException. It sounds like more generic exception and
> means for me literally any error excepting NotFoundService exception.
> What's the difference with \Exception then?
>
> On Wednesday, November 23, 2016 at 5:07:48 PM UTC+3, GeeH wrote:
>>
>> Yes we do need an explicit exception, because create errors should be
>> handled differently from service not being found.
>>
>> G
>>
>> On Wednesday, 23 November 2016 13:05:00 UTC, Daniel Plainview wrote:
>>>
>>> > These are different errors and could/should be handled differently.
>>>
>>> I think we all agree on this point. The question is do you need
>>> explicit CreationException and why?
>>>
>>> On Wednesday, November 23, 2016 at 2:08:40 PM UTC+3, GeeH wrote:
My opinion is this:
NotFoundException - we don't have a service for this key, you've messed
up your configuration somewhere
CreationException - argh, something went wrong creating your service,
this is probably a bug or coding problem
These are different errors and could/should be handled differently.
G
On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote:
>
> @Larry
>
> > Those would imply different people are doing something wrong, so
> it's a different person's responsibility to fix.
>
> It is already clear. If it is not NotFoundServiceException, then it is
> not user's fault. No need to have yet another exception.
> So we return to the same question: what's the use case when you need
> to catch MisconfiguredServiceExceptionInterface?
>
> On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield
> wrote:
>>
>> We discussed the exception handling at the php[world] meeting, and
>> the general consensus from those in the room was that semantically
>> "missing", "broken", and "other" are distinct error conditions that
>> should
>> be treated separately. To that end I offer the following PR so there's
>> something concrete to discuss:
>>
>> https://github.com/php-fig/fig-standards/pull/844
>>
>> As far as use case, beyond the semantic distinction "missing" implies
>> the caller is doing something wrong. "Broken" means the configuration
>> is
>> wrong. (Even if the configuration in this case is a hard-coded class,
>> it's
>> still configuration so it's in-scope for PSR-11, not PSR-11-followup.)
>> Those would imply different people are doing something wrong, so it's a
>> different person's responsibility to fix.
>>
>> --Larry Garfield
>>
>> On 11/11/2016 01:42 PM, Daniel Plainview wrote:
>>
>> > So why even mention it then?
>>
>> I think it's because most implementations are not aware of this
>> difference, but it's important.
>> It doesn't automatically mean that the interface must reflect the
>> DependencyNotFoundException.
>> @throws FooException means "it's your possible issue, take care of
>> it".
>> @throws DependencyNotFoundException means "My arm can be broken, take
>> care of it".
>> @throws ConfigrationDoesNotExistException means "My leg is broken,
>> take care of it".
>>
>> > As someone building a framework that uses a container I would very
>> much care about the distinction between group 2 and group 3
>>
>> Could you, please, provide us a real use-case when you need to catch
>> DependencyNotFoundException?
>>
Re: [REVIEW] PSR-16 Simple Cache
Hi Jordi (et al.), nice job! Tbh I was a bit surprised as I haven't seen any discussion about it at all after the entrance vote and I wasn't aware of it being worked on anywhere outside this ML. My fault, as I've probably missed that communication and didn't check or ask around. That said, below are my major gripes with it, inherited from PSR-6. I understand where "MUST treat an item as expired once its Expiration Time is reached" comes from, and I would agree, but for a cache it makes little sense to be so strict and adamant about it. An entry that has a TTL of 30 seconds is probably going to be fine at 31s too, especially if expiration can't be expressed as a point in time. Relaxing that would allow implementations to conform to the PSR-6 interface and adding stampede protection the same way apc(u) / squid do, i.e. returning a slightly stale item while a single process is updating the cache. Not a deal-breaker, but "SHOULD treat an item as expired" can be implemented as "always treat..." if anyone so desires, whereas the opposite is not possible. Other than that, I also am not very fond of null meaning either never or some unspecified default value. A library would be forced to pick one as there's no way to set an item to never expire if a default is available. I personally like being able to specify a default TTL, but I would trade that in exchange for something cleaner and clearer. Alternatively, I'd suggest adding something like CacheInterface::setDefaultTTL() and CacheInterface::TTL_NEVER = -1, with support for the latter being subject to the actual storage capabilities. Cheers On 16/11/2016 15:22, Jordi Boggiano wrote: > Heya, > > We believe PSR-16, Simple Cache, is now ready for final review. As > coordinator, I hereby open the mandatory review period prior to a formal > acceptance vote; voting will begin no earlier than December 1st, 2016. > > Here are links to the most current version and its meta document: > > https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md > > > https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md > > > > The package containing the interfaces is there: > > https://github.com/php-fig/simplecache > > > The latest important changes to the interfaces can be found at: > > https://github.com/php-fig/simplecache/releases/tag/0.2.0 > > > And FWIW, Scrapbook already provides a PSR-16 implementation in its > upcoming release: > https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php > > > > Thanks for your time reviewing! > > Cheers > -- Matteo Beccati Development & Consulting - http://www.beccati.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/5ed473d6-0d38-6da9-4b0a-7fe1bcbe0641%40beccati.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSR-11] Exceptions
> because create errors should be handled differently from service not
being found
Sure. We already can do it:
try {
$this->container->get('foo');
} catch (NotFoundService $e) {
// ...
} catch (\Exception $e) {
// Configuration syntax error, circular dependencies, etc.
}
Why do you need CreationException, can you provide some use cases when you
want to catch exactly this exception?
By the way, I don't know if you did it on purpose, but your name
(CreationException) seems more vague than Larry's
MisconfiguredServiceException. It sounds like more generic exception and
means for me literally any error excepting NotFoundService exception.
What's the difference with \Exception then?
On Wednesday, November 23, 2016 at 5:07:48 PM UTC+3, GeeH wrote:
>
> Yes we do need an explicit exception, because create errors should be
> handled differently from service not being found.
>
> G
>
> On Wednesday, 23 November 2016 13:05:00 UTC, Daniel Plainview wrote:
>>
>> > These are different errors and could/should be handled differently.
>>
>> I think we all agree on this point. The question is do you need
>> explicit CreationException and why?
>>
>> On Wednesday, November 23, 2016 at 2:08:40 PM UTC+3, GeeH wrote:
>>>
>>> My opinion is this:
>>>
>>> NotFoundException - we don't have a service for this key, you've messed
>>> up your configuration somewhere
>>> CreationException - argh, something went wrong creating your service,
>>> this is probably a bug or coding problem
>>>
>>> These are different errors and could/should be handled differently.
>>>
>>> G
>>>
>>> On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote:
@Larry
> Those would imply different people are doing something wrong, so it's
a different person's responsibility to fix.
It is already clear. If it is not NotFoundServiceException, then it is
not user's fault. No need to have yet another exception.
So we return to the same question: what's the use case when you need to
catch MisconfiguredServiceExceptionInterface?
On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield
wrote:
>
> We discussed the exception handling at the php[world] meeting, and the
> general consensus from those in the room was that semantically "missing",
> "broken", and "other" are distinct error conditions that should be
> treated
> separately. To that end I offer the following PR so there's something
> concrete to discuss:
>
> https://github.com/php-fig/fig-standards/pull/844
>
> As far as use case, beyond the semantic distinction "missing" implies
> the caller is doing something wrong. "Broken" means the configuration is
> wrong. (Even if the configuration in this case is a hard-coded class,
> it's
> still configuration so it's in-scope for PSR-11, not PSR-11-followup.)
> Those would imply different people are doing something wrong, so it's a
> different person's responsibility to fix.
>
> --Larry Garfield
>
> On 11/11/2016 01:42 PM, Daniel Plainview wrote:
>
> > So why even mention it then?
>
> I think it's because most implementations are not aware of this
> difference, but it's important.
> It doesn't automatically mean that the interface must reflect the
> DependencyNotFoundException.
> @throws FooException means "it's your possible issue, take care of it".
> @throws DependencyNotFoundException means "My arm can be broken, take
> care of it".
> @throws ConfigrationDoesNotExistException means "My leg is broken,
> take care of it".
>
> > As someone building a framework that uses a container I would very
> much care about the distinction between group 2 and group 3
>
> Could you, please, provide us a real use-case when you need to catch
> DependencyNotFoundException?
>
> On Friday, November 11, 2016 at 9:19:11 PM UTC+3, Larry Garfield
> wrote:
>>
>> I'm not suggesting converting all exceptions that might possibly
>> happen to MisconfiguredServiceException. I'm saying there's 3 broad
>> categories:
>>
>> 1) What you asked for doesn't exist.
>> 2) What you asked for is broken.
>> 3) Something else happened, WTF? (Eg, a database-backed container
>> has a missing DB.)
>>
>> I agree that group 3 is out of scope. Group 1 is already covered.
>> The question is group 2, where "there is something wrong with the
>> container
>> but it's not that what you asked for is missing" is, I assert,
>> legitimately
>> in scope. As someone building a framework that uses a container I would
>> very much care about the distinction between group 2 and group 3. That
>> doesn't mean fully exploring all possible details of group 2 and what
>> might
>> break, just indicating the separation between groups 2 and 3.
Re: [PSR-11] Exceptions
> These are different errors and could/should be handled differently. I think we all agree on this point. The question is do you need explicit CreationException and why? On Wednesday, November 23, 2016 at 2:08:40 PM UTC+3, GeeH wrote: > > My opinion is this: > > NotFoundException - we don't have a service for this key, you've messed up > your configuration somewhere > CreationException - argh, something went wrong creating your service, this > is probably a bug or coding problem > > These are different errors and could/should be handled differently. > > G > > On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote: >> >> @Larry >> >> > Those would imply different people are doing something wrong, so it's a >> different person's responsibility to fix. >> >> It is already clear. If it is not NotFoundServiceException, then it is >> not user's fault. No need to have yet another exception. >> So we return to the same question: what's the use case when you need to >> catch MisconfiguredServiceExceptionInterface? >> >> On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield wrote: >>> >>> We discussed the exception handling at the php[world] meeting, and the >>> general consensus from those in the room was that semantically "missing", >>> "broken", and "other" are distinct error conditions that should be treated >>> separately. To that end I offer the following PR so there's something >>> concrete to discuss: >>> >>> https://github.com/php-fig/fig-standards/pull/844 >>> >>> As far as use case, beyond the semantic distinction "missing" implies >>> the caller is doing something wrong. "Broken" means the configuration is >>> wrong. (Even if the configuration in this case is a hard-coded class, it's >>> still configuration so it's in-scope for PSR-11, not PSR-11-followup.) >>> Those would imply different people are doing something wrong, so it's a >>> different person's responsibility to fix. >>> >>> --Larry Garfield >>> >>> On 11/11/2016 01:42 PM, Daniel Plainview wrote: >>> >>> > So why even mention it then? >>> >>> I think it's because most implementations are not aware of this >>> difference, but it's important. >>> It doesn't automatically mean that the interface must reflect the >>> DependencyNotFoundException. >>> @throws FooException means "it's your possible issue, take care of it". >>> @throws DependencyNotFoundException means "My arm can be broken, take >>> care of it". >>> @throws ConfigrationDoesNotExistException means "My leg is broken, take >>> care of it". >>> >>> > As someone building a framework that uses a container I would very >>> much care about the distinction between group 2 and group 3 >>> >>> Could you, please, provide us a real use-case when you need to catch >>> DependencyNotFoundException? >>> >>> On Friday, November 11, 2016 at 9:19:11 PM UTC+3, Larry Garfield wrote: I'm not suggesting converting all exceptions that might possibly happen to MisconfiguredServiceException. I'm saying there's 3 broad categories: 1) What you asked for doesn't exist. 2) What you asked for is broken. 3) Something else happened, WTF? (Eg, a database-backed container has a missing DB.) I agree that group 3 is out of scope. Group 1 is already covered. The question is group 2, where "there is something wrong with the container but it's not that what you asked for is missing" is, I assert, legitimately in scope. As someone building a framework that uses a container I would very much care about the distinction between group 2 and group 3. That doesn't mean fully exploring all possible details of group 2 and what might break, just indicating the separation between groups 2 and 3. The current text says, in essence, "for group 2, throw anything but the same as group 1". So why even mention it then? And no, that's not a suggestion to remove yet more things from the spec. :-) (That way lies more incompatibility.) I'm saying there should be a clearly defined exception for group 1, a clearly defined parent exception for group 2 (subclasses specific to a given implementation entirely welcome), and group 3 is not-our-problem. --Larry Garfield On 11/07/2016 12:20 PM, Daniel Plainview wrote: The major problem with unchecked exceptions is that it is not class consumer business. What do you say when someone throws SomethingIsBrokenInsideOfMe to you? I'd say "hey, take a vacation, fix yourself, you look unhealthy". Is it not my business what exactly is broken (leg or arm, whatever, it doesn't help to fix my issue). But it is fair enough if library throws YouAreWrong exception in my face when I'm screwed up. When you make a typo in your Container implementation, it could fail with something like \TypeError. It is "unhappy-path", isn't it? Is
php[world] Meeting
Hi, Did anyone take notes/minutes of the meeting at php[world] please, and if so will the be posted to the list please? G -- 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/433ea4a6-e453-45eb-8137-e587c9a4b9f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSR-11] Exceptions
My opinion is this: NotFoundException - we don't have a service for this key, you've messed up your configuration somewhere CreationException - argh, something went wrong creating your service, this is probably a bug or coding problem These are different errors and could/should be handled differently. G On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote: > > @Larry > > > Those would imply different people are doing something wrong, so it's a > different person's responsibility to fix. > > It is already clear. If it is not NotFoundServiceException, then it is not > user's fault. No need to have yet another exception. > So we return to the same question: what's the use case when you need to > catch MisconfiguredServiceExceptionInterface? > > On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield wrote: >> >> We discussed the exception handling at the php[world] meeting, and the >> general consensus from those in the room was that semantically "missing", >> "broken", and "other" are distinct error conditions that should be treated >> separately. To that end I offer the following PR so there's something >> concrete to discuss: >> >> https://github.com/php-fig/fig-standards/pull/844 >> >> As far as use case, beyond the semantic distinction "missing" implies the >> caller is doing something wrong. "Broken" means the configuration is >> wrong. (Even if the configuration in this case is a hard-coded class, it's >> still configuration so it's in-scope for PSR-11, not PSR-11-followup.) >> Those would imply different people are doing something wrong, so it's a >> different person's responsibility to fix. >> >> --Larry Garfield >> >> On 11/11/2016 01:42 PM, Daniel Plainview wrote: >> >> > So why even mention it then? >> >> I think it's because most implementations are not aware of this >> difference, but it's important. >> It doesn't automatically mean that the interface must reflect the >> DependencyNotFoundException. >> @throws FooException means "it's your possible issue, take care of it". >> @throws DependencyNotFoundException means "My arm can be broken, take >> care of it". >> @throws ConfigrationDoesNotExistException means "My leg is broken, take >> care of it". >> >> > As someone building a framework that uses a container I would very much >> care about the distinction between group 2 and group 3 >> >> Could you, please, provide us a real use-case when you need to catch >> DependencyNotFoundException? >> >> On Friday, November 11, 2016 at 9:19:11 PM UTC+3, Larry Garfield wrote: >>> >>> I'm not suggesting converting all exceptions that might possibly happen >>> to MisconfiguredServiceException. I'm saying there's 3 broad categories: >>> >>> 1) What you asked for doesn't exist. >>> 2) What you asked for is broken. >>> 3) Something else happened, WTF? (Eg, a database-backed container has a >>> missing DB.) >>> >>> I agree that group 3 is out of scope. Group 1 is already covered. The >>> question is group 2, where "there is something wrong with the container but >>> it's not that what you asked for is missing" is, I assert, legitimately in >>> scope. As someone building a framework that uses a container I would very >>> much care about the distinction between group 2 and group 3. That doesn't >>> mean fully exploring all possible details of group 2 and what might break, >>> just indicating the separation between groups 2 and 3. >>> >>> The current text says, in essence, "for group 2, throw anything but the >>> same as group 1". So why even mention it then? And no, that's not a >>> suggestion to remove yet more things from the spec. :-) (That way lies >>> more incompatibility.) I'm saying there should be a clearly defined >>> exception for group 1, a clearly defined parent exception for group 2 >>> (subclasses specific to a given implementation entirely welcome), and group >>> 3 is not-our-problem. >>> >>> --Larry Garfield >>> >>> On 11/07/2016 12:20 PM, Daniel Plainview wrote: >>> >>> The major problem with unchecked exceptions is that it is not class >>> consumer business. >>> What do you say when someone throws SomethingIsBrokenInsideOfMe to you? >>> I'd say "hey, take a vacation, fix yourself, you look unhealthy". Is it not >>> my business what exactly is broken (leg or arm, whatever, it doesn't help >>> to fix my issue). But it is fair enough if library throws YouAreWrong >>> exception in my face when I'm screwed up. >>> >>> When you make a typo in your Container implementation, it could fail >>> with something like \TypeError. It is "unhappy-path", isn't it? Is >>> it MisconfiguredServiceException? I don't think so. What do you do then? >>> You go and fix your implementation. What happens if configuration is >>> broken? You go and fix it as well. I don't see much difference here. >>> >>> MisconfiguredServiceException for me is an illusory solution for >>> "unhappy-path". You can't trust it. What does it exactly mean?
