These days, the cache backends used with Spring's caching abstraction are very frequently remote services (such as Redis, Memcached, Hazelcast in client-server topology...) which implies dealing with concerns such as networking, (de)serialization. These concerns mean there's far bigger chance of various (most often transient) errors occurring while interacting with the cache backend, unlike in-JVM cache solutions that dominated over a decade ago when caching abstraction was added to Spring.
With that in mind, I personally don't think SimpleCacheErrorHandler is a sensible default for the cache error handler as it breaks the application flow that's otherwise perfectly functional, just because the optimization (cache) was unavailable at that particular moment. Instead, the better option is to have LoggingCacheErrorHandler (with enabled stacktrace logging) as the default.
This is something that could be considered for 6.0.
Comment From: snicoll
LoggingCacheErrorHandler has been added as a convenience for those who chose to let such exceptions be moved to log statements. The core framework couldn't use this by default, even in 6.0.
For what it is worth, this has been asked to the Spring Boot team as well.
Comment From: vpavic
I had hoped to at least get some reasoning on why the team believes current behavior is a better default. I didn't see the issue in Boot tracker, but having looked at it there's no reasoning offered there either.
The way I see it, throwing errors (and potentially implying data loss) in a situation where the decorated application functionality is perfectly operational is not desirable. So, developers have to either opt into LoggingCacheErrorHandler or some specific error handling that will yield the same effect - treating cache backend failure as a cache miss.
Hence the proposal to revisit the default because new major releases and opportunities to do so don't come often.
I'd also like to emphasize that unlike other AOP based advices (transactions, async and so on...) caching is purely performance optimization oriented decoration that does not (or shouldn't really) have an impact on application from a functional standpoint.
Finally, note that the CacheErrorHandler as a concept is barely mentioned in the reference manual with its only mention being in Cache annotation settings table in 8.2.6. Enabling Caching Annotations. So it's also not that hard to miss the impact and the risks of the default behavior.