In other words, that solution is still within your method's range. Alternately, if you merely want to respect an interruption request, you can do so without InterruptedException being involved:. For yet another variation, consider the case where your method must either complete all its work or indicate to the caller that it could not complete it, and it takes a while to get there, but you want to respect thread interruption.
Something like this will suffice:. Note there that we called on Thread interrupted , which has the side effect of clearing the thread's interruption status if it had been set.
If that method returns true, we as the caller have accepted the responsibility to hold and communicate that interruption status. In this case, since we do not assume that we created the calling thread and we don't have enough scope visible here to know what its interruption policy is, we communicated the interruption status we observed and adopted by throwing InterruptedException.
Labeling a method as "blocking" is always a matter of degree; every method blocks its caller for some amount of time. The distinction you may be looking for is whether the method blocks waiting on some external input, such as a user pressing a key or a message arriving over a network.
In those cases, advertising that you throw InterruptedException indicates to your caller that your method is safe for use by callers from threads that must control their latency.
You're saying, "This may take a while to complete, but it will take no longer than you're willing to wait. InputStream read , which threatens to block until one of three conditions occur, none of which is the caller's thread being interrupted.
The situations in which one will detect the current thread's interruption and swallow it are usually confined to those where you, the author, created the thread in question, and you have committed to exiting the thread's run method once the thread gets interrupted.
That's the notion of "cooperative cancellation," wherein you observe the request for your thread to stop running, and you decide to abide by that request by finishing your work as quickly as possible and letting the thread's call stack unwind.
Again, though, unless you're the author of the thread's run method, you swallowing the thread's interruption status is likely harming the intended behavior of your callers and of the other methods upon which they call. I suggest that you study the topic of a thread's interruption status , and get comfortable with the methods Thread isInterrupted , Thread interrupted , and Thread interrupt. Once you understand those, and see that an InterruptedException being in flight is an alternate representation of Thread isInterrupted having returned true, or a courteous translation of Thread interrupted having returned true, this should all start making more sense.
InterruptedException is usually thrown when thread blocked on a method gets interrupt called on it. The point of it is to unblock for some reason a thread that is blocked.
Example of reason is application shutdown. So, when you shutdown your application, if you have threads waiting on let say sleep or wait , if you do not tell them that you are shutting down they will continue to wait. If those threads are not daemon threads, then your application won't shutdown. So, when thread gets interrupted during sleep , you have to check the conditions and handle the situation. In case of shutdown, you have to check your shutdown flag and eventually do the clean-up work and let the thread go.
Threads can be interrupted because of some other reasons, but the point is the same. If you have multi-threaded application you have to establish protocol for your threads so that they know when there is some special condition how to handle it.
If your method blocks, it should catch and handle InterruptedException , and prefer not to re-throw it. Also, the method may block in several places - each place should catch and handle InterruptedException in a way appropriate for the place where it could be thrown.
The bible on the subject of multi-threaded code is Java Concurrency in Practice. I highly recommend you read it. Thus, properly written concurrent code should catch InterruptedException. You can chose to re-throw it or throw your own application-specific exception. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? If you know you'll never interrupt such code this safely avoids needing to wrap your sleep calls in a try-catch block.
More often, however, you cannot guarantee that your thread will never be interrupted. In particular if you're writing code that will be executed by an Executor or some other thread-management it's critical that your code responds promptly to interrupts, otherwise your application will stall or even deadlock. In such cases the best thing to do is generally to allow the InterruptedException to propagate up the call stack, adding a throws InterruptedException to each method in turn.
This may seem kludgy but it's actually a desirable property - your method's signatures now indicates to callers that it will respond promptly to interrupts. In limited cases e. If you call Thread.
That would be a severe violation of the entire Java multi-threading idea. Our owner the owner of our thread is asking us to stop, and we just ignore it. This is what most of us are doing with InterruptedException :. They may just catch a runtime exception there, and the thread will remain alive. The owner of the thread will be disappointed. We have to inform the higher level that we just caught an interruption request. Such behavior would be too irresponsible. The entire thread received an interruption request, and we merely swallow it and convert it into a RuntimeException.
Now, nobody will blame us for having an irresponsible attitude toward a valuable flag. We found it in true status, cleared it, set it back to true , and threw a runtime exception. You can find a more detailed and official description of this problem here: Java Theory and Practice: Dealing With InterruptedException. Please, use syntax highlighting in your comments, to make them more readable.
JavaScript is disabled in your browser, that's why you can't see comments under this post. So, how do we stop a thread when we need it to stop? Sound logical so far?
0コメント