Let’s discuss what you can do about annoying InterruptedException. In many situations you’d have a lot of methods like someOtherMethod() below, where you’d want to preserve it’s signature clear. Or, you call goes through 3-rd party interfaces which do not throw InterruptedException. What do you do? First of all you have to know what kind of application do you write:
- Web application like Servlet or Struts controller;
- EBJ bean;
- Applet;
- Desktop or mobile rich application;
- Single-threaded console application;
- Multi-threaded console application;
After you know it, you can estimate if interrupt even is going to happen and how it should affect your application. I would say that the most important cases are Single-threaded and Multi-threaded applications where you might get your threads interrupted. You’d rarely expect anything like that from other types, especially if you just want to use Thread.sleep(). Than you should decide if your application would be interruptable. I would only consider interruptable case here. Non-interruptable case is clearly described here. In case
of Single-threaded application you’d probably want to do something to address it and it is more or less straight-forward, in multi-threaded application you’d probably have some monitoring thread which would eventually check health status of applications and would do something about it (like you might want to start a new thread or shutdown the whole application in case of on of thread being interrupted), but still you might want to do some clean-up on lowest level. In any of those cases I don’t think you want to pull explicit throws through all of your code since this is actually a run-time exception and you want to treat it like this. Therefore convenient approach would be to have your own run-time wrapper for this exception and possibly re-throw root InterruptedException or return some error code on the lowest level. Let me show here what I am talking about. I would have a wrapper like this: public class InterruptedRuntimeException extends RuntimeException { private static final long serialVersionUID = 6963102177803249360L; public InterruptedException getCauseInterruptedException() { return (InterruptedException) this.getCause(); } public InterruptedRuntimeException(String message, InterruptedException cause) { super(message, cause); } public InterruptedRuntimeException(InterruptedException cause) { super(cause); } } Which would work this way: public class ExceptionHandling { public static int main(String[] args) { try { someOtherMethod(); } catch (InterruptedRuntimeException e) { return 2; } return 0; } private static void someOtherMethod() { throwingMethod(); } private static void throwingMethod() { try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new InterruptedRuntimeException("Your Message", e); } } } For a single threaded application. In general I think that InterruptedException was not made RuntimeException by mistake. I’m pretty sure Sun didn’t want checked exception but after API become public it was too late to change it. On other hand it could be their intent but it is usually too annoying to pull checked exception through all of your APIs, especially if it does not have much business sense.
Artem's Blog 