[ 
https://issues.apache.org/jira/browse/QPID-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-6694:
-----------------------------
    Description: 
We have a number of cases in asynchronous model operations where we chain code 
to run after a future completes, returning a future to the caller that 
completes once the chained code completes.

The idiom looks like this:

{code:java}
public ListenableFuture<Void> doMyStateChangeOp() 
{
  final SettableFuture<Void> returnVal = SettableFuture.create();
  ListenableFuture opFuture = operationAsync();
  opFuture.addListener(new Runnable()
  {
                // some code
                returnVal.set(null);
  });
  return returnVal;
}
{code} 

where #addListener executes the Runnable when the future opFuture completes, 
successfully or otherwise.  The idiom suffers from the fact that opFuture 
contains an exception, the exception itself is lost.  The caller who receives 
returnVal gets a success future and the exception is effectively swallowed.
 

  was:
We have a number of cases in asynchronous model operations where we chain code 
to run after a future completes, returning a future to the caller that 
completes once the chained code completes.

The idiom looks like this:

{code:java}
final SettableFuture<Void> returnVal = SettableFuture.create();
ListenableFuture opFuture = operationAsync();
opFuture.addListener(new Runnable()
{
                // some code
                returnVal.set(null);
});
{code} 

where #addListener executes the Runnable when the future opFuture completes, 
successfully or otherwise.  The idiom suffers from the fact that opFuture 
contains an exception, the exception itself is lost.  The caller who receives 
returnVal gets a successfully future and the exception is effectively swallowed.
 


> Ensure that future wiring within async model operations preserve exceptions
> ---------------------------------------------------------------------------
>
>                 Key: QPID-6694
>                 URL: https://issues.apache.org/jira/browse/QPID-6694
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: qpid-java-6.0
>            Reporter: Keith Wall
>             Fix For: qpid-java-6.0
>
>
> We have a number of cases in asynchronous model operations where we chain 
> code to run after a future completes, returning a future to the caller that 
> completes once the chained code completes.
> The idiom looks like this:
> {code:java}
> public ListenableFuture<Void> doMyStateChangeOp() 
> {
>   final SettableFuture<Void> returnVal = SettableFuture.create();
>   ListenableFuture opFuture = operationAsync();
>   opFuture.addListener(new Runnable()
>   {
>                 // some code
>                 returnVal.set(null);
>   });
>   return returnVal;
> }
> {code} 
> where #addListener executes the Runnable when the future opFuture completes, 
> successfully or otherwise.  The idiom suffers from the fact that opFuture 
> contains an exception, the exception itself is lost.  The caller who receives 
> returnVal gets a success future and the exception is effectively swallowed.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to