[concurrency-interest] More Javadoc problems

Peter Levart peter.levart at gmail.com
Fri Dec 19 14:42:43 EST 2014


On 12/19/2014 05:45 PM, cowwoc wrote:
> Hi Josh,
>
> Can you give a concrete example where observers would witness 
> side-effects?

Try this:


public class CFTest {

     static void sleep(long millis) {
         try {
             Thread.sleep(millis);
         } catch (InterruptedException e) {
         }
     }

     public static void main(String[] args) throws Exception {

         CompletableFuture<Integer> cf1 = 
CompletableFuture.supplyAsync(() -> {
             sleep(200L);
             throw new RuntimeException("1st");
         });

         cf1.whenComplete((i, e1) -> {
             if (e1 != null) {
                 sleep(100L);
                 RuntimeException e2 = new RuntimeException("2nd");
                 e1.addSuppressed(e2); // this is what is desired right?
                 throw e2;
             }
         });

         try {
             cf1.join();
         } catch (CompletionException e) {
             System.out.println("\n1st print:\n");
             e.printStackTrace(System.out);
             sleep(200L);
             System.out.println("\n2nd print:\n");
             e.printStackTrace(System.out);
         }
     }
}

>
> Assuming what you say is possible, would you object to throwing a 
> clone of the original exception instance with the suppressed 
> exceptions added? This way only observers of the 2nd completion stage 
> would observe these changes.

Exceptions are not generally Cloneable.

Regards, Peter


> Gili
>
> On 19/12/2014 10:40 AM, Josh Humphries wrote:
>> I do not disagree. Though one thing to note of this approach is that 
>> "observers" of the original completion stage (that failed with 
>> exception 1) will now witness side effects from a *successor* 
>> completion stage via the suppressed exception. It might be a little 
>> odd for some consumers to see the state of the Throwable change 
>> /after/ it has already been (potentially) published to multiple threads.
>>
>> I would personally vote that the later completion stage fail 
>> exceptionally with exception2. But that's a change in behavior that 
>> is likely to be a non-starter due to being incompatible with the 
>> current spec (even if only slightly).
>>
>> The actual authors of the library are on this list and can likely 
>> chime in further about why it behaves that way.
>>
>>
>>
>> ----
>> *Josh Humphries*
>> Manager, Shared Systems  |  Platform Engineering
>> Atlanta, GA  |  678-400-4867
>> *Square* (www.squareup.com <http://www.squareup.com>)
>>
>> On Fri, Dec 19, 2014 at 9:50 AM, cowwoc <cowwoc at bbs.darktech.org 
>> <mailto:cowwoc at bbs.darktech.org>> wrote:
>>
>>     Hi Josh,
>>
>>     Thanks for the follow-up.
>>
>>     I'd like to request two changes:
>>
>>      1. Add exception2 as a suppressed exception (eating exceptions
>>         is like silent failures... it's bad business)
>>      2. Have the Javadoc to mention what will happen in this case.
>>
>>
>>     Let me know what you think.
>>
>>     Thanks,
>>     Gili
>>
>>     On 19/12/2014 9:42 AM, Josh Humphries [via JSR166 Concurrency] wrote:
>>>     Looking at the source code -- the ultimate spec ;) -- the
>>>     original exception is preferred. So in your example, the
>>>     resulting CompletionStage completes exceptionally with
>>>     exception1, and exception2 is effectively eaten.
>>>
>>>     ----
>>>     *Josh Humphries*
>>>     Manager, Shared Systems  |  Platform Engineering
>>>     Atlanta, GA  | 678-400-4867 <tel:678-400-4867>
>>>     *Square* (www.squareup.com <http://www.squareup.com>)
>>>
>>>     On Fri, Dec 19, 2014 at 9:00 AM, cowwoc <[hidden email]
>>>     <http:///user/SendEmail.jtp?type=node&node=11671&i=0>> wrote:
>>>
>>>         Hi guys,
>>>
>>>         The Javadoc for CompletableFuture.whenComplete() reads:
>>>
>>>         "If the supplied action itself encounters an exception, then
>>>         the returned
>>>         stage exceptionally completes with this exception unless
>>>         this stage also
>>>         completed exceptionally."
>>>
>>>         Huh?!
>>>
>>>         So if the original stage completed with exception1 but the
>>>         handler threw
>>>         exception2, which exception does the returned
>>>         CompleteableFuture complete
>>>         with? The specification says what *won't* happen if the
>>>         stage also completed
>>>         exceptionally, but it doesn't say what *will* happen. Please
>>>         clarify :)
>>>
>>>         Thanks,
>>>         Gili
>>>
>>>
>>>
>>>         --
>>>         View this message in context:
>>>         http://jsr166-concurrency.10961.n7.nabble.com/More-Javadoc-problems-tp11669.html
>>>         Sent from the JSR166 Concurrency mailing list archive at
>>>         Nabble.com.
>>>         _______________________________________________
>>>         Concurrency-interest mailing list
>>>         [hidden email]
>>>         <http:///user/SendEmail.jtp?type=node&node=11671&i=1>
>>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>>     _______________________________________________
>>>     Concurrency-interest mailing list
>>>     [hidden email]
>>>     <http:///user/SendEmail.jtp?type=node&node=11671&i=2>
>>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>>     ------------------------------------------------------------------------
>>>     If you reply to this email, your message will be added to the
>>>     discussion below:
>>>     http://jsr166-concurrency.10961.n7.nabble.com/More-Javadoc-problems-tp11669p11671.html
>>>
>>>     To unsubscribe from More Javadoc problems, click here.
>>>     NAML
>>>     <http://jsr166-concurrency.10961.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>>     ------------------------------------------------------------------------
>>     View this message in context: Re: More Javadoc problems
>>     <http://jsr166-concurrency.10961.n7.nabble.com/More-Javadoc-problems-tp11669p11672.html>
>>
>>
>>     Sent from the JSR166 Concurrency mailing list archive
>>     <http://jsr166-concurrency.10961.n7.nabble.com/> at Nabble.com.
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     Concurrency-interest at cs.oswego.edu
>>     <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141219/4f9284cf/attachment.html>


More information about the Concurrency-interest mailing list