Question: I'm trying to understand how threads work in Java and currently investigating how to implement looped threads that can be cancelled. Here's the code:

```
public static void main(String[] args) throws Exception {
    Thread t = new Thread() {
        @Override
        public void run() {
            System.out.println("THREAD: started");
            try {
                while(!isInterrupted()) {
                    System.out.printf("THREAD: working...\n");
                    Thread.sleep(100);
                }
            } catch(InterruptedException e) {
                // we're interrupted on Thread.sleep(), ok

                // EDIT
                interrupt();

            } finally {
                // we've either finished normally
                // or got an InterruptedException on call to Thread.sleep()
                // or finished because of isInterrupted() flag

                // clean-up and we're done
                System.out.println("THREAD: done");
            }               
        }
    };

    t.start();
    Thread.sleep(500);
    System.out.println("CALLER: asking to stop");
    t.interrupt();
    t.join();
    System.out.println("CALLER: thread finished");
}

```

The thread I create is *indended* to be interrupted sooner or later. So, I check isInterrupted() flag to decide whether I need to go on and also catch `InterruptedException` to handle cases when I'm in a kind of waiting operation (`sleep`, `join`, `wait`).

Things I'd like to clarify are:

1. Is it fine to use interruption mechanism for this kind of task? (comparing to having `volatile boolean shouldStop`)
2. Is this solution correct?
3. Is it normal that I swallow InterruptedException? I'm not really interested what was the piece of code where someone asked my thread to interrupt.
4. Are there any shorter ways to solve this problem? (the main point is having 'infinite' loop)

**EDIT**
Added call to `interrupt()` in catch for `InterruptedException`.

Answer: 
1. Yes, it's fine. You should document how a Thread/Runnable must be stopped. You could add a dedicated stop method on your Runnable implementation that encapsulates the stopping mechanism. Either use interrupt, or use a dedicated boolean value, or both.
2. Yes, except the good practice is to restore the interrupt status when catching InterruptedException: `Thread.currentThread().interrupt();`
3. No, you should restore the interrupt status
4. None that I'm aware of
1) The way in your example is preferable to using a volatile flag (which is redundant since you already have the interrupted flag), according to the *Java Concurrency in Practice* book. It is how InterruptedExceptions were intended to be used.

2) Yes

3) you can eat the exception as long as you restore the interrupt flag status. The exception doesn't represent an error so eating it doesn't lose any information, it is purely a means of transferring control. (Restoring the interrupt flag status is important for cases where you have nested control structures that each need to be informed that the thread is cancelling, for a simple example like yours it's good form but if it's missing it won't hurt anything.)

4) no