<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote" style=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think that combining join with throwIsFailed is perfectly reasonable, and it even was a design we considered but preferred the STS one for pedagogical reasons (we hope to learn if that decision was the right one). </blockquote><div><br></div><div>I actually don't mind that they are separate, to be honest.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But representing cancellation (i.e. interruption) — a perfectly valid behaviour for correct code even in the case of no environmental errors — as an unchecked exception, which usually represents a bug, is not the Java way. Obviously anyone is free to do that, but it’s not something we would consider for a standard API.<br></blockquote><div><br></div><div>The interrupted exception is a necessary evil I suppose. Still, it sure would be convenient if throwIfFailed could have an unchecked version for those cases where none of the subtasks in a scope throw any checked exceptions. Perhaps we could have an alternate version of STS which accepts Supplier instead of Callable?</div></div><input name="virtru-metadata" type="hidden" value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"1","compose-window":{"secure":false}}"></div>