[concurrency-interest] Swing translates InterruptedException to Error

Joseph Bowbeer jozart@csi.com
Fri, 6 Jun 2003 12:06:28 -0700


I reported some major problems with readLock and writeLock back in '99.

Originally, writeLock just ate the exception:

        } catch (InterruptedException e) {
            // safe to let this pass... write lock not
            // held if the thread lands here.

This was later changed to a non-checked exception.  (Non-checked in order to
preserve the method signature.)

At the time, I believed there were other problems with the support for
asynchonous loading in AbstractDocument as well:

    "AbstractDocument supports reading the document asynchronously and then
sending the update events to DocumentListeners (in the reading thread).
Aside from the incomplete, fragile implemention, the design does not account
for the fact that the DocumentListeners are part of Swing's single-threaded
subsystem.  I see no extensible way to insert an asynchronous model into a
single-threaded subsystem (with stateless events) such as Swing's."

I can send more details if you'd like.

----- Original Message ----- 
From: "Tom Cargill" <cargill@profcon.com>
To: <concurrency-interest@altair.cs.oswego.edu>
Sent: Friday, June 06, 2003 9:35 AM
Subject: [concurrency-interest] Swing translates InterruptedException to

[If this is off-topic, just ignore me.]

I just encountered the following code in


The practice of translating an InterruptedException to an Error
strikes me as bizarre. Can anyone offer a rationale for this policy?


void writeLock() {
   try {
     while ((numReaders > 0) || (currWriter != null)) {
       if (Thread.currentThread() == currWriter) {
         if (notifyingListeners) {
           throw new IllegalStateException(
            "Attempt to mutate in notification");
     currWriter = Thread.currentThread();
     numWriters = 1;
   } catch (InterruptedException e) {
     throw new Error("Interrupted attempt to aquire write lock");