7

This is a question on old Java when we were making our own Threads. Some methods like Thread.sleep(100) throw an InterruptedException when it is interrupted by another thread. Now as I understand, interruption means another thread is saying: Let me take over now.

When this happens, why does Java want us to deal with InterruptedException?

The programmer should not even need to care when the threads are interrupting each other. He should be just able to divide the work between threads and be notifed when it is done. So what is the reason of Java wanting us to deal with InteruptedException? At the very least it should be RuntimeException

ziesemer
  • 27,712
  • 8
  • 86
  • 94
Victor
  • 16,609
  • 71
  • 229
  • 409

4 Answers4

8

The programmer should not even need to care when the threads are interrupting each other

This is not true. There are many, many situations in which you want to know that an interruption has been requested, but you will ignore it for a little bit to finish the job you are doing.

For example, suppose one thread opens a file and starts writing some data. This thread, then, blocks, waiting for the rest of the data to be calculated. Suppose that a second thread tries to interrupt the first one. What should it do? Simply die, and maybe you end up with a corrupt, incomplete file? Should it cleanup by deleting the file it started writing? Should it ignore the interruption request and just wait for the end of the data it has to write? Should it write something meaning "I was interrupted here", so that it can continue its work from that point the next time?

On a different scenario, suppose you have an HTTP server. Suppose users are accessing your server, and, say, downloading a big file from it. You want to stop the server. The application will then try to interrupt all the worker threads. What should they do? Simply stop the downloads? Or should they wait for the users to finish downloading their files and only after that they should die, without accepting any more requests? Both scenarios are equally valid.

As you see, there are way too many possible scenarios, and it would be terrible if we had no way to know that an interruption has been requested. Sometimes, you will simply let the thread die. Sometimes, you must clean up the environment. Sometimes, you want it to finish the request it is working on but not accept any more requests.

Bruno Reis
  • 37,201
  • 11
  • 119
  • 156
  • 2
    Not sure how this answers the question - everything you've written above would be just as readily achievable if InterruptedException were unchecked. – Peter Jul 13 '16 at 05:12
  • @Peter The fact that it's checked requires the user of your API which can throw the exception to explicitly deal with it somehow. If it were unchecked and uncaught, it would just throw the exception and possibly terminate the program which means all of the above cases of corrupt files and interrupted connections are possible. Making it checked is a way of making sure the user definitely does not miss the important part of handling the exception. – Snackoverflow Jul 24 '17 at 09:01
4

It seems you're mixing between the thread scheduler and interruption.

A thread scheduler is rather a native system, that divides jobs from multiple threads into processes. If too many threads are active, the scheduler will work asynchronously. In other words let me take over for now might be quite true.

An interrupt means, quit what you are currently doing and don't go back to it. The most practical way to implement this, is with an exception.

Mordechai
  • 15,437
  • 2
  • 41
  • 82
  • 2
    According to Oracle, http://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html, *"An interrupt means, quit what you are currently doing and **don't go back to it**"*, is not quite correct. It says: "An interrupt is an indication to a thread that it should stop what it is doing and do something else. **It's up to the programmer to decide exactly how a thread responds to an interrupt**". there's no standard behaviour such as "don't go back to it". An interrupt is just one way of a threading signaling something to another thread, and this may be implemented to mean "quit" or not – Bruno Reis Apr 08 '13 at 22:26
1

An InteruptedException is thrown when a thread is forcibly interrupted. This isn't a usual situation (i.e. when the thread is context switched out by the scheduler). Examples would be when another thread manually interupts it or the process receives a SIGINT signal.

SimonC
  • 6,590
  • 1
  • 23
  • 40
  • SIGKILL won't interrupt threads; it directly kills them, it kills the whole JVM process. – Bruno Reis Apr 08 '13 at 04:07
  • Sorry, my bad, I meant `SIGINT`. – SimonC Apr 08 '13 at 04:11
  • SIGINT won't call `.interrupt()` on threads either. It will just possibly run any shutdown hook you've added. If it did interrupt threads, it could cause havoc: you might need to terminate your threads in a very specific order, how would the JVM know the correct order? – Bruno Reis Apr 08 '13 at 04:14
  • 2
    Thanks @BrunoReis, you are correct. I'd always had the assumption threads would get interrupted on `SIGINT`. I'll have to revisit a few lines of clean-up code now... – SimonC Apr 08 '13 at 04:26
1

RuntimeExceptions are supposed to represent programming errors (see http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html). InterruptedException is more like a signal from another thread.

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275