Simply re-throwing a checked exception in the form of a runtime-exception is a bad habbit. So for the scenarios in which the second approach is desirable, I'd say never.
In the particular case of InterruptedException
I would say it depends on the specific situation. Do you care about interrupts?
Examples:
Usually, when I perform a Thread.sleep
I care little about interrupts, and I just ignore the exception.
If I'm doing some blocking read etc, it's a completely different story. I may for instance redo the read if I was interrupted, or I may want to try to close the stream.
A third option is to rethrow the (checked) InterruptedException
. In some cases however (when you're for instance implementing an interface method, that is not declared to throw this exception) you should go for your first approach.
Here is a good article on the subject: http://www.ibm.com/developerworks/java/library/j-jtp05236.html
When a blocking method detects interruption and throws InterruptedException, it clears the interrupted status. If you catch InterruptedException but cannot rethrow it, you should preserve evidence that the interruption occurred so that code higher up on the call stack can learn of the interruption and respond to it if it wants to. This task is accomplished by calling interrupt() to "reinterrupt" the current thread, as shown in Listing 3.