[infinispan-dev] Unwrapping exceptions

[Sanne Grinovero]

Yes please make sure that the kind of end users exceptions are the
same for the client, regardless if the originator happens to be an
owner as well.

It's valuable to know that the exception happened on another node, but
the exception type (and primary message) should be the same.

Bonus points to not have exceptions at all :)
In Elasticsearch they developed a new scripting language for a use
case similar to our "lambda execution" which basically restricts in
the language itself what is safe to do vs what you can't do.
I'm not sure about developing a new language but from this point of
view it's brilliant..



On 29 August 2016 at 17:54, Radim Vansa <rvansa at redhat.com> wrote:
> The intention was not to protect the user from knowing where the code
> was executed, but rather simplify exception handling when he wants to
> handle different exceptions from his code (though, throwing exception on
> remote node is not too efficient). And the argument was that he does not
> *need* to know it.
>
> As for the debugging aid, it could make sense to add the remote stack
> trace to suppressed exceptions, though I don't think that it will be of
> any use to him.
>
> R.
>
> On 08/29/2016 06:07 PM, Dan Berindei wrote:
>> -1, I don't think we need to protect the user from knowing that his
>> lambda was executed on a remote node. On the contrary, it might help
>> him/her with debugging.
>>
>> FWIW, I don't think the cache should ever throw the exact exception
>> that the lambda raised - I'd always wrap it in some kind of
>> CacheException.
>>
>> Cheers
>> Dan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev