[concurrency-interest] Having TimeoutException be a subclass of InterruptedException

David Holmes dholmes@dltech.com.au
Mon, 9 Dec 2002 12:05:23 +1000

Luke Blanshard wrote:
> Once upon a time, catching an InterruptedException or an
> InterruptedIOException always implied that the current
> thread had been interrupted by another thread.

InterruptedIOException never specified the nature of the interruption.
In fact on most systems the only time you would ever get an
InterruptedIOException was when a socket timeout occurred because the
interaction between Thread.interrupt and blocking I/O operations has
never been properly specified, has never worked to any sense of
"completeness" on any platform and has been completely abandoned - see
the java.nio response to interrupting a blocked thread

If you can accept that the intent was to have a range of possible
mechanisms for "interrupting" a blocking action in a thread, does that
make things more tenable for you?

I would agree that the current specification for InterruptedException
is too strong because it implies a direct connection with
Thread.interrupt and doesn't seem to allow other reasons for

> The problem I have with both of these choices is that they
> change the implicit contract of their parent classes.

For InterruptedException as currently described yes.

I wish I had some really old 1.02 and 1.1 docs.

> So here's my constructive suggestion.  Let's make the contract
> by adding a boolean wasThreadInterrupted() method to both
> InterruptedException and InterruptedIOException.

There is no need for a boolean method to test this. The concrete type
of the exception tells the same information:
   try { /* ... */ }
   catch(TimeoutException ex) { /* definitely a timeout */}
   catch(InterruptedException ex) { /* a general interrupt */

As I said previously no existing code is broken by the new exception
because that code can't be using any of the new methods. So when you
start using  new method you add the more selective catch clauses.

David Holmes