[concurrency-interest] More Javadoc problems

cowwoc cowwoc at bbs.darktech.org
Fri Dec 19 11:45:38 EST 2014


Hi Josh,

Can you give a concrete example where observers would witness side-effects?

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.

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
>

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


More information about the Concurrency-interest mailing list