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 <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.
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 <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
