On 08/30/2016 02:16 PM, Dan Berindei wrote: > On Tue, Aug 30, 2016 at 1:11 PM, Sanne Grinovero <sa...@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. > >> 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 <rva...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
