None of the things you list produce an InterruptedException.
The only thing that can interrupt a thread is a call to Thread#interrupt(). The JLS is relatively clear on the matter, from section 17.2.3:
17.2.3 Interruptions
Interruption actions occur upon invocation of Thread.interrupt, as well as
methods defined to invoke it in turn, such as ThreadGroup.interrupt.
See the official tutorial on interrupts for some more info as well. Specifically:
A thread sends an interrupt by invoking interrupt on the Thread object for the thread to be interrupted. For the interrupt mechanism to work correctly, the interrupted thread must support its own interruption.
...
The interrupt mechanism is implemented using an internal flag known as the interrupt status. Invoking Thread.interrupt sets this flag. When a thread checks for an interrupt by invoking the static method Thread.interrupted, interrupt status is cleared. The non-static isInterrupted method, which is used by one thread to query the interrupt status of another, does not change the interrupt status flag.
By convention, any method that exits by throwing an InterruptedException clears interrupt status when it does so. However, it's always possible that interrupt status will immediately be set again, by another thread invoking interrupt.
The implication is that it is an explicit flag settable only by calling interrupt(), rather than triggered by other unknown external events. This is further implied by the description of the exception in various methods that throw it, for example (emphasis mine):
InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.
The purpose of the interrupt system in general is to provide a common, well-defined framework for allowing threads to interrupt tasks (potentially time-consuming ones) in other threads. While you could implement similar functionality with explicit logic in your own application, having this well-defined mechanism allows independent classes (e.g. the JDK, other third-party code, other independent classes in your own code) to provide this functionality in a consistent way.
The many notes and "warnings" you see about handling InterruptedException aren't meant to imply that they can be thrown completely spontaneously, they are meant to encourage well-designed objects that can be used in contexts that are not known yet, where interrupt() would be presumed to work (so really, you do want to assume they can be thrown spontaneously if you are creating reusable objects that will be robust in future situations - i.e. you're never guaranteed that your code won't be some day used by somebody who expects interrupts to work).
For quick one-off projects you don't really need to worry about special handling for these exceptions as long as you know for certain that you aren't calling interrupt() and aren't calling something that can call interrupt(), but be aware of the implications of that in the long run, especially if you end up reusing that code in other contexts.
