<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>InterruptedException is special, making it unchecked would make it
      more hazardous than it is already. This is because throwing
      InterruptedException clears the interrupted status. If you catch
      the exception then you must remember to reset the interrupted
      status when continuing without re-throwing the exception. This
      ensures that code that executes subsequently can also respond to
      the request to finish up.</div></blockquote><div><br></div><div>It would have been better if InterruptedException would be in its own unchecked hierarchy (i.e. not an `Exception`), but likely that would be too big of a breaking change now. Today's reality is that you can rest assured that some code you are calling will clear the interrupted status (in a better case throwing some unknown exception type instead). That is, thread interrupts are completely unreliable, I had the unluck to go into the nightmare of it, and design a lot of APIs around it where I simply treat `InterruptedException` as a bug (aside from low level APIs designed for it). It is way more pleasant than thread interrupts.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span>
      As regards STS.join throwing InterruptedException then it
      shouldn't be a surprise. The other APIs in this area do the same.
      We know </span><span>InterruptedException
      and the interrupted status are hard to use. </span><span>There
      are some ideas for making the existing thread interruption
      mechanism easier to use but nothing close to a proposal/JEP at
      this time.</span></div></blockquote><div><br></div><div>I also had much-much time in this area - including implementations which work in production for many-many years now -, so I would most certainly be interested in those discussions. Which list would be used for it, if it happens?</div><div><br></div><div>Though the JDK is in a more difficult spot than I was when it comes to implementing it, I would say a sensible approach would be the following:</div><div><br></div><div>1. Declare an unchecked `OperationCancelledException` (it is actually worth considering to make it its own unchecked hierarchy rather than `RuntimeException` (I mean not even `Exception`), though there are some obvious downsides), a `CancellationToken` and a `CancellationController` (with relatively obvious roles). Though there are some very non-obvious gotchas implementing them as I have learned in the past.</div><div><br></div><div>2. Have a dedicated scoped value (maybe even specially stored for efficiency?) storing a `CancellationToken`.</div><div><br></div><div>3. Provide a utility method `handleCancellationInterrupt` which could be called in a catch of `InterruptedException` or simply when detecting interrupts.</div><div><br></div><div>4. Create alternatives to methods throwing `InterruptedException` which rely on the new cancellation mechanism. E.g.: `await` -> `awaitCancelably`.</div><div><br></div><div>Attila</div></div></div>