ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Evdokimov <sevdoki...@gridgain.com>
Subject Re: IgniteException throws from asynchronous cache operation.
Date Fri, 20 Mar 2015 15:12:19 GMT
I've created a ticket: https://issues.apache.org/jira/browse/IGNITE-527
(Asynchronous cache operations must throw CacheException instead of

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
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 <dsetrakyan@apache.org>

> 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 <sevdokimov@gridgain.com
> >
> 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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message