The CacheException is RTE, so no call stack methods are required to catch and some calls are far from the actual throw code and might not be fully aware of this RTE.
What this means is if an operation fails, and you haven't correctly protected your top level web from uncaught exceptions, the fail hits the browser and ugly error. (this was the die part - a little melodramatic perhaps) If the operations is say, node unavailable, then your cache implementation is unhealthy and no amount of retry is going to help. Shiro doesn't handle any ShiroCache Exceptions from what I can tell, so it is left to the developer to figure out a strategy. What is the community consensus on handling CacheExceptions? Thanks Dom On 26 September 2014 18:47, Les Hazlewood <[email protected]> wrote: > What do you mean 'die'? Wouldn't that particular operation just fail? > > I'd be happy to hear what people want the behavior to be - we can always > improve. > > -- > Les Hazlewood | @lhazlewood > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > > On Thu, Sep 25, 2014 at 12:28 AM, domfarr <[email protected]> wrote: > >> I have a question about handling org.apache.shiro.cache.CacheException. >> >> What is shiro's responsibility when a cache exception occurs? This RTE >> ripples through the whole stack, but I'm unclear where it is handled and >> in >> what manner. Can a shiro enabled web application recover? Is the cache >> manager reinitialised? Do I have to restart? >> >> For example, a timeout exception or a failed to connect to node exception >> occurs on cache.get(key). What's the expected outcome apart from bubble to >> the stop and die? >> >> Thanks >> >> >> >> -- >> View this message in context: >> http://shiro-user.582556.n2.nabble.com/CacheExceptions-tp7580255.html >> Sent from the Shiro User mailing list archive at Nabble.com. >> > >
