Hazelcast has a future now too? I wonder where they got that idea :) Our future overrides the Future.get() method specifically to remove all checked exceptions from it. This way we make it pretty clear that it will never throw ExecutionException. I actually like our design.
D. On Fri, Mar 20, 2015 at 8:12 AM, Sergey Evdokimov <[email protected]> wrote: > I've created a ticket: https://issues.apache.org/jira/browse/IGNITE-527 > (Asynchronous cache operations must throw CacheException instead of > IgniteException) > > The reason of ExecutionException is separation exception that is > computation result and other exceptions > like CancellationException, InterruptedException. I don't say that our > approach is bad (throwing exception directly without wrapping into > ExecutionException), but we must honor contract described in > java.util.concurrent.Future > because IgniteFuture extends java.util.concurrent.Future. Theoretically, > user can pass our IgniteFuture to third party code as a simple > java.util.concurrent.Future, third party code will expect > ExecutionException > and java.util.concurrent.TimeoutException when call "get(...)". Hazelcast's > future has method 'getSafely()' that throws RuntimeException directly, but > "get()" works according to java.util.concurrent.Future contract. > > > > > On Fri, Mar 20, 2015 at 5:13 PM, Dmitriy Setrakyan <[email protected]> > wrote: > > > Agree that sync and async counterparts for the same operation should > > through the same exception. Is it really not the case now? If not, we > > should fix it. > > > > Disagree about ExecutionException, as the only reason it was done is to > > support checked exceptions. We have runtime exception, so we can throw > the > > correct exception at all times. > > > > D. > > > > On Fri, Mar 20, 2015 at 5:32 AM, Sergey Evdokimov < > [email protected] > > > > > wrote: > > > > > Hello, > > > > > > Failed cache operations throw CacheException, but failed asynchronous > > > operations throw IgniteException. I think it's wrong. Same synchronous > > and > > > asynchronous operation must throw same exception. > > > > > > BTW. According to contract of java.util.concurrent.Future#get() if > result > > > of operation is an exception Future#get() should throw > ExecutionException > > > that wrap result exception. We break this contract and throw result > > > exception directly from Future#get(), this may be cause of problems, > for > > > example it's impossible to make out exceptions that threw during > > > computation and other runtime exceptions. > > > I propose to keep contract of Future#get() as described in JDK javadocs > > and > > > add our method "take" that throw exception directly as implemented at > > > Ignite currently. > > > > > >
