Personally as a user I'd expect to have a CacheException raised if and
only if it's not caused by my own code.
Imagine my own lambda is explicitly throwing an exception of a type of
my choice, it would be nice to receive that error and not a different
one.
On 28 April 2017 at 11:38, Katia Aresti <karesti(a)redhat.com> wrote:
Hi all !
Radim pointed me to this thread discussing the exceptions launched by the
lambda executed by the user.
So, I've came accros this problem right now with the compute method.
ComputeIfAbsent is used by the QueryCache [1]
This method is now a Command, so when the wrapped lambda throws an
exception, [2], the expected exception is the one raised by the lambda. But
with my modifications, this exception is wrapped in a CacheException.
I discussed with Adrien yesterday, and IMHO and his, a CacheException is not
the same thing as the exception raised inside the lambda. Moreover, in this
particular case, I don't know if users some code could be broken if we make
the user get a CacheException that wrappes the ParseException instead of the
ParseException itself.
How can I fix the problem ?
Should we correct the tests and say that, from now on, CacheException will
be raised ?
Should we handle this CacheException in the QueryCache class when
computeIfAbsent is called ?
Should we propagate the lambda's exception as it is ?
Katia
[1]
https://github.com/infinispan/infinispan/blob/master/query/src/main/java/...
[2]
https://github.com/infinispan/infinispan/blob/master/query/src/test/java/...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev