This feels more like a hack than a fix. As is, it would actually be impossible to debug issues with the cache storage because you will arbitrarily catch them all and alter the operation in a way that can only be caught if you have the logging plugin turned on.

The cache API is not the place to be implementing high level error handling behaviors like this. It is correctly designed to throw errors in a way that consumers of the API can (and should if developers would properly catch and handle errors) catch them and decide locally if it is a critical failure or one that can be gracefully worked around (all throughout "critical" infrastructure pieces we are doing just that in core).

Obviously I disagree or I wouldn't have done this. It is not impossible to debug because you should be logging while you're debugging and you should probably be logging warning and above at all times anyway.

However, maybe there is some case where you'd rather not fall back. Since an $options object is passed in, maybe it could optionally contain an array of alternate handler names that could be tried before finally deciding to fail. The default case would still be to throw the exception.

This might be a valid "keep things working" fix for a production environment, but in a development environment, this is not the type of error that you want to be blindly caught and ignored. The best fix for this issue is for developers to implement proper error handling mechanisms in their extensions. I think we've updated almost every use of JCache in core so that it implements said error handling, which covers all of the base use cases except for a developer who explicitly calls into the caching API on their own.

It is not impossible to debug because you should be logging while you're debugging and you should probably be logging warning and above at all times anyway.

Let's be honest here. How many people are running the logging plugin in production or have written their own logging mechanism to catch these types of issues? For that matter, where in our documentation is it written to guide users on how to most optimally configure Joomla logging? With the current code and error handling mechanisms, you will get a notification in some form of there being platform issues (filesystem permissions, Memcached down) that you'd want to investigate ASAP but with this change odds are you're going to miss that notification.

I do basically agree that the developer should handle the error. My problem was that there was (seems to be fixed now) code shipping with Joomla that caused this error and did not catch it. As long as that's fine, I'm satisfied, actually.