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

+1 for Sanne I would expect the same and I suppose one or more customers will raise this issue On Fri, Apr 28, 2017 at 12:56 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > 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&gt; 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/s > rc/main/java/org/infinispan/query/dsl/embedded/impl/QueryCache.java#L79 > > [2] > > https://github.com/infinispan/infinispan/blob/master/query/s > rc/test/java/org/infinispan/query/dsl/embedded/QueryDslCondi > tionsTest.java#L1913 > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev