[infinispan-dev] Unwrapping exceptions

[Dan Berindei]

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.

> 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