Menu
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
445
InterruptedException ) is a checked exception [6] which directly extends java. lang. Exception . This exception is thrown when a thread is waiting, sleeping, or otherwise occupied, and the thread is interrupted, either before or during the activity [7].
What Is an InterruptedException? An InterruptedException is thrown when a thread is interrupted while it's waiting, sleeping, or otherwise occupied. In other words, some code has called the interrupt() method on our thread. It's a checked exception, and many blocking operations in Java can throw it.
InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the information that the thread was interrupted will be lost.
If the blocking network call throws an InterruptedException your method can not finish computation in a normal way. You let the InterruptedException propagate. If no, then you should not declare your method with throws InterruptedException and you should (must!) catch the exception.
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.
149
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.
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
