Is throwing InterruptedException essential when stopping threads? Can I use another exception type?

Question

I have tournament code for students' codes. Therefore I have no control over the students' codes.

I need to implement timeout for students' code calls (they run in separate threads). So I instrumented their code and inserted right after loop and method definitions the following code:

if (Thread.interrupted()) throw new InterruptedException();

The problem is InterruptedException is checked, and therefore I have to add throws declarations to all methods, which can break overriding methods' signatures.

So I thought I could not throw InterruptedException, but an unchecked one, e.g. RuntimeException. Can I do it? Will there be some difference?

In my tournament code I start the students' code as a futrure in an ExecutorService and try to get the result using get() with timeout.

Answer 1

InterruptedException is suggested by java spec: you can find more information here

http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html

Answer 2

If you want a simple timeout and do not care about the code terminating gracefully you could use Thread.stop(). The use of stop() is discourage because it throws a ThreadDeathException in that Thread regardless what its currently doing. By injecting code that throws an Exception in every loop you are doing essentially the same (aside from jdk code terminating normaly). So in that special case I would suggest using stop().

But if you rather want to throw the checked InterruptedException unchecked, there is a hack for that as well.

here is an example of how to stop Thread using a ScheduledExecutorService

void runWithHardTimeOut(final Runnable task, long timeout, TimeUnit unit) {

    final Thread[] runner = new Thread[1];
    final AtomicBoolean done = new AtomicBoolean(false);

    Runnable killer = new Runnable() {

        @Override
        public void run() {
            if (!done.get()) {
                while (runner[0] == null);
                if (done.get()) {
                    return;
                } else {
                    runner[0].stop();
                }
            }
        }
    };
    final Runnable r = new Runnable() {

        @Override
        public void run() {
            try {
                runner[0] = Thread.currentThread();
                killerExecutor.schedule(killer, timeout, unit);
                task.run();
                done.set(true);
            } catch (ThreadDeath wrench) {}
        }
    };

    executor.execute(r);
}

Answer 3

The interrupt status of a worker thread in the standard ExecutorService implementations will be cleared when a task is completed, and it's ignored for the purposes of testing whether a task was canceled before completion (as detected by Future.isCancelled()).

So, you can safely throw an unchecked ("runtime") exception rather than InterruptedException, and it won't interfere with the operation of the ExecutorService.

However, if you are still concerned, you can preserve the interrupt status by re-asserting it:

if (Thread.interrupted()) {
  Thread.currentThread().interrupt();
  throw new IllegalStateException("Time limit exceeded.");
}

Or using a different method that doesn't clear it:

if (Thread.currentThread().isInterrupted()) 
  throw new IllegalStateException("Time limit exceeded.");

Normally custom runtime exceptions are a bad idea, because they can result in leaky abstractions, but here, a custom type in place of IllegalStateException may make it cleaner for you to distinguish your timeout exceptions from runtime exceptions raised by the student's code.

---

Update: Canceling a task running with ExecutorService is only reliable if the task is written correctly to support interruption, and you can't trust students to do that.

So your options are:

1. Manually review the source code, inserting interruption detection where necessary.
2. Get rid of ExecutorService and create worker threads yourself. Use the stop() or stop(Throwable) method to terminate the threads after timeout. To be truly robust, use a byte code engineering library like ASM to automate analysis of the compiled plugin code to see if it can catch the Throwable (or ThreadDeath or the custom Throwable) you are using to stop() the worker thread.
3. Fork Java processes to run the agent code, and kill the whole process after timeout.

Answer 4

I need to implement timeout for students' code calls (they run in separate threads). So I instrumented their code and inserted right after loop and method definitions the following code:
if (Thread.interrupted()) throw new InterruptedException();

It is not common for user code to throw InterruptedException. For example, I've written a ton of thread code that uses interrupts but I've never thrown InterruptedException myself. I'll quit the thread, return false, or throw some other exception if a task is interrupted instead.

Since you don't have control over the students' code then I think the best mechanism would be to manage your own threads and use thread.stop(). The reason why stop() is deprecated is that any objects that are current locked and being modified will be in an unknown state when the thread is killed. However, if the students' code is not modifying any shared state then this is not an issue.

Your code could do something like the following:

• I would wrap the code in some sort of wrapping Runnable so you know when each code starts and when it ends. You could also catch ThreadDeath to know when thread.stop() had to be called.
• Run each of the wrapped students' code in a thread.
• Then join with each thread in turn with a timeout. If the timeout expires then call thread.stop().

Something like:

public class WrappedRunnable implements Runnable {
    private Runnable delegate;
    long startTimeMillis;
    long endTimeMillis;
    boolean threadDeath;
    public WrappedRunnable(Runnable delegate) {
       this.delegate = delegate;
    }
    public void run() {
        startTimeMillis = System.currentTimeMillis();
        try {
            delegate.run();
        } catch (ThreadDeath td) {
            threadDeath = true;
        }
        endTimeMillis = System.currentTimeMillis();
    }
}