[infinispan-dev] Unwrapping exceptions

[Sanne Grinovero]

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 at 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/org/infinispan/query/dsl/embedded/impl/QueryCache.java#L79
> [2]
> https://github.com/infinispan/infinispan/blob/master/query/src/test/java/org/infinispan/query/dsl/embedded/QueryDslConditionsTest.java#L1913
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev