The tick method prints a dot every pauseTime milliseconds up to a maximum of count timessee "Timer
and TimerTask" on page 653 for a better way to do this. If something interrupts the thread in which tick is
running, sleep will throw InterruptedException. The ticking will then cease, and the catch clause
will reinterrupt the thread. You could instead declare that tick itself throws InterruptedException
and simply let the exception percolate upward, but then every invoker of tick would have to handle the
same possibility. Reinterrupting the thread allows tick to clean up its own behavior and then let other code
handle the interrupt as it normally would.
In general any method that performs a blocking operation (either directly or indirectly) should allow that
blocking operation to be cancelled with interrupt and should throw an appropriate exception if that
occurs. This is what sleep and wait do. In some systems, blocking I/O operations will respond to
interruption by throwing InterruptedIOException (which is a subclass of the general IOException
that most I/O methods can throwsee Chapter 20 for more details on I/O). Even if the interruption cannot be
responded to during the I/O operation, systems may check for interruption at the start of the operation and
throw the exceptionhence the need for an interrupted thread to clear its interrupted state if it needs to perform
I/O as part of its cleanup. In general, however, you cannot assume that interrupt will unblock a thread
that is performing I/O.
Every method of every class executes in some thread, but the behavior defined by those methods generally
concerns the state of the object involved, not the state of the thread executing the method. Given that, how do
you write methods that will allow threads to respond to interrupts and be cancellable? If your method can
block, then it should respond to interruption as just discussed. Otherwise, you must decide what interruption
or cancellation would mean for your method and then make that behavior part of the methods contractin the
majority of cases methods need not concern themselves with interruption at all. The golden rule, however, is
to never hide an interrupt by clearing it explicitly or by catching an InterruptedException and
continuing normallythat prevents any thread from being cancellable when executing your code.
The interruption mechanism is a tool that cooperating code can use to make multithreading effective. Neither
it, nor any other mechanism, can deal with hostile or malicious code.
14.8.2. Waiting for a Thread to Complete
One thread can wait for another thread to terminate by using one of the join methods. The simple form waits
forever for a particular thread to complete:
class CalcThread extends Thread {
private double result;
public void run() {
result = calculate();
}
public double getResult() {
return result;
}
public double calculate() {
// ... calculate a value for "result"
}
}
class ShowJoin {
public static void main(String[] args) {
CalcThread calc = new CalcThread();
calc.start();
doSomethingElse();
try {
calc.join();