core
core copied to clipboard
fuel
Cache key not existing is not an exceptional circumstance
Cache::get throws an exception if the cache key is not found. Nonexistence is the default state of all cache keys; this behaviour appears to be contrary to the philosophy of the Arr class, which protects us from PHP thinking it's exceptional for an array key not to exist.
Returning null or the default - like Arr::get - is preferable, I think.
Indeed, _get() conflates all problems into one return false. The problem could be anything from key not existing to cache being gone, as far as I can tell.
In fact the exception could easily be thrown from me simply storing boolean false in the cache - I'll have to test this to confirm it, though.
Edit - not sure this is what's happening but it's definitely wrong to throw an exception just because a cache key is not there. That's expected, not exceptional.
This is a big debate in "cache country", and in the PSR/FIG group.
The reason for the exception is very simple: any value (and that includes null or false) is a valid return value from a Cache get(). So what exactly do you want to use to signal a non-hit?
The FIG folks are coming up with very complex solutions involving a multi-stage process, where you get first, and get an object returned on which you have to check isHit() or isMiss().
Personally, I find it a lot easier to do
try
{
$var = Cache::get('key');
}
catch (\CacheException $e)
{
$var = 'a new value';
Cache::set('key', $var);
}
The idea behind not using a default here is that you're trying to get something from Cache, so you obviously want something cached. Then you don't want a default, you want to populate the cache as soon as possible.
Erlier myself was also a fan of false/null if cache did not exist, until I came to the project where 0,1,null,false,true all were valid Cached items. here the exceptions helped!
Cache can only be SET BY your application (it cannot be done other way), so when it tries to get something from the cache and it is not found, that is exceptional, because it is expected to be set.
Unlike arrays can be set many ways (data outside of your application, etc), so you cannot expect any keys to be set.
depending on the driver in use, some of them don't consider a missing key like an error. Memcached for example doesn't throw an error if the key is missing but instead just return '' (empty) and the PECL PHP driver returns false and I think this is the behaviour that should be followed IMHO.
I don't. If I don't want that behaviour, then I don't select that backend.
For a lot of situations, there is a difference between "there is nothing in cache" which will trigger an action in code to gather data and store it in cache before returning it, and "the cache value is empty" which will not trigger that action, as you have a cached value (which turns out to be an empty string).
Sooner or later a Caching PSR will be out. After the decision is made about implementing it or not, this can be solved by the PSR.
From what I have seen sofar I'm not so sure the PSR is a viable alternative. But we'll see.