[infinispan-dev] Unwrapping exceptions

[Radim Vansa]

On 08/30/2016 02:47 PM, Radim Vansa wrote:
> On 08/30/2016 02:16 PM, Dan Berindei wrote:
>> On Tue, Aug 30, 2016 at 1:11 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>>> 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.
>>>
>> Is it really a problem if the local exceptions are wrapped in
>> CacheException, and the remote ones are wrapped in RemoteException?
>> RemoteException is a subtype of CacheException, so `catch
>> (CacheException e)` works with all of them.
>>
>> Future.get() wraps all exceptions in ExecutionException,
>> CompletableFuture.join() wraps all exceptions in CompletionException.
>> So we'd be an outlier if we *didn't* wrap user exceptions.
> Okay, the exceptions can be wrapped in one (and always exactly one)
> level of CacheException. Not as convenient for filtering (try-catch
> block vs. instanceofs on e.getCause()), but makes (enough) sense. I'll
> adapt the PR.

Hmm, it's not possible to use only one remote exception - if the command 
fails on backup (before failing on primary), we should keep the hierarchy as
RemoteException (from primary) caused by RemoteException (from backup) 
caused by (actual failure).

Radim

>>> Bonus points to not have exceptions at all :)
>> Error codes FTW? ;)
>>
>>> 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..
>>>
>> I think you impose the same kind of restrictions at the bytecode
>> level, with something like JaQue [1]. Still, considering that you also
>> need a way to ship the lambda to the server, a DSL doesn't sound too
>> bad.
>>
>> [1]: https://github.com/TrigerSoft/jaque
>>
>>> 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.
>>>>
>> But does the user really need to know that it was an exception in
>> their lambda vs an exception in Infinispan itself? Most of the time,
>> there's nothing you can do about it anyway...
>>
>>>> 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.
>>>>
>> If we throw the exact exception that the lambda raised on the remote
>> node, the user is going to see *only* the remote stack trace.
>>
>> TBH we have the same problem with RemoteExceptions now: instead of
>> having a stack trace pointing to the user code calling into
>> Infinispan, our stack trace points to the Infinispan code handling the
>> response. But at least we have a chance to "fix" the stack trace of
>> the wrapper exception in AsyncInterceptorChainImpl.invoke to that it
>> has the caller's stack trace instead. If we don't have a wrapper,
>> that's no longer possible.
>>
>> 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