<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-12-19 22:41 GMT+03:00 Chris Purcell <span dir="ltr"><<a href="mailto:chris.purcell.39@gmail.com" target="_blank">chris.purcell.39@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Behaving like handle() makes sense, but wasn't strictly speaking one of the survey options. Will you (a) open a new survey, (b) throw B-with-A-suppressed (survey option 2), or (c) throw B (like handle)? I'd vote for C.</div></div></div></blockquote><div><br></div><div>+ 1 for just throwing B without A suppressed. </div><div><br></div><div>When I receive normal result X and then transform it to Y inside my *new* completion stage, it doesn't mean that I "suppressed" X. Likewise, throwing an exception from a new completion stage should not mean that I suppressed previous exception. Instead, most likely it means that user *processed* previous exception and transformed it into some other form.</div><div><br></div><div>try-with-resources is not very good analogy here, because it has a single control flow. If the first exception is thrown from try-block and then the control flow is disturbed by the second exception from close() method, we end up with two pending unrelated exceptions. Both of them must be propagated further somehow and this is where suppression comes into play.</div><div>To the contrast, "whenComplete" and "invoke" create new control flow. And as there is no ambiguity, it is not clear why A should be suppressed. Looks like we can simply forget about it.<br></div><div><br></div><div>Vladimir.</div></div></div></div>