Hi sorry to come late in the story. I'm the author of the PSR-6 implementation in Symfony Cache 3.1.
There are more grey zones on PSR-6 and maybe an errata should address them also? Below is the list I computed. First, on the very matter of this topic, IMHO the best behavior is to trigger an InvalidArgumentException. Here is why: - there is no BC issue: the behavior on this case was not defined in the spec; and we cannot reasonably expect that someone wrong some *working* code that expects *not* getting an exception here. - because the spec says that InvalidArgumentException are expected in some situations, users should already be prepared to deal with them. - and last but not least: hey! this is really an invalid argument! As far as DX is concerned, it would be inconsistent to have different argument handling strategies in the spec. IMHO again, triggering an E_USER_ERROR would be make PSR-6 implementation very fragile. In the same way that having a lib that calls "exit()" is a really bad practice, using E_USER_ERROR would be fatal by default, unless one uses a custom that error handler that triggers... an exception (or would that break PSR-6 again?). By my own personal standards, I tend avoid using any lib that exit() of E_USER_ERROR. Please don't force me (us) to break this principle. I've read that InvalidArgumentException is not possible per the spec. But if you read that full paragraph again, it rationale is built for *runtime errors* triggered "by an underlying data store". The situation here is not the same: providing a wrong argument to a $item->expire*() is a devtime issue. It won't happend reasonably at runtime. Thus, I thing the argument against InvalidArgumentException does not apply. As promised, here is my list of grey zones in PSR-6, with the behavior implemented in Symfony in brackets: - What happens when one provides an unserializable value to save? ($pool->save/commit() returns false. Note the difference with the previous issue: CacheItemInterface throws, CacheItemPoolInterface does not throw, that's the rule I inferred.) - What happens when one of several values can't be saved? (the serializable ones are saved, the others ignored and $pool->save/commit() returns false) - What happens when a value cannot be *un*serialized? (return a miss) Should we allow a __PHP_Incomplete_Class? (no) - What happens when an already expired or negative lifetime item is saved? (invalidate any existing value & return true) - Are deferred items subject to expiration? (yes) - Is getting a deferred item a hit? (yes) - Are deferred items commited atomically? (no) - Should we store a `null` value for items that were a "miss" but have no value set? (yes) - Should committed item objects have isHit() === true after being saved? (no: not when miss at the origin) - What's the rationale for having reserved characters in keys, and why these ones specifically? (no idea) Given that we already managed to answer all those questions while implementing the spec, I hope we didn't make any mistake in interpreting the PSR. Please tell me if we did anything wrong here. For future implementers, it could maybe help to make some of these points less implicit and more explicit? I'll let you cherry-pick :) Cheers, Nicolas -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAOWwgpmmH2Py258YsUP-goN%3DeW%3DvWVT942vuf7cTELbXoN7Y8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
