The Cause of InterruptedException - java

From J2me doc we know that:
java.lang.InterruptedException Thrown when a thread is waiting, sleeping, or otherwise paused for a long time and another thread interrupts it.
The question is if it's posible to get such exception if from one thread i call Thread.Interupt() for other thread where Run() method of other thread waiting on InputStream.Read(char[]buf) ?

The behavior of blocking read in response to thread interrupt is, in fact, undefined. See this long-standing bug for details. The short of it is that sometimes you get EOF, sometimes you get IOException.

Unfortunately, no, the java.io.* classes do not respond to interruptions when they are blocked in read or write methods. Typically what you have to do is close the stream and then handle the IOException that gets thrown. I have this pattern repeated throughout my code:
try {
for (;;) {
try {
inputStream.read(data);
thread.join();
}
catch (IOException exception) {
// If interrupted this isn't a real I/O error.
if (Thread.interrupted()) {
throw new InterruptedException();
}
else {
throw exception;
}
}
}
}
catch (InterruptedException exception) {
}
Alternatively the newer java.nio.* classes do handle interruptions better and generate InterruptedIOExceptions when they are interrupted. Note that this exception is derived from IOException and not from InterruptedException so you will probably need two catch clauses to handle either type of exception, one for InterruptedException and one for InterruptedIOException. And you'll want any inner IOException catch clause to ignore InterruptedIOExceptions.

Related

In java how can I catch an exception thrown from child thread and then throw it again from the parent thread

I currently have the following sample code that I am trying to convert OutputStream to InputStream, which I got the idea from Method 2 in http://blog.ostermiller.org/convert-java-outputstream-inputstream
But my question here is, the save method could throw IOException, and I would like to catch that and re-throw that as part of this getInputStream method.
I am trying to wrap the IOException thrown by save(out) to a runtime exception, but I know that this runtime exception cannot be caught by the parent thread. So I am stuck on this, can anyone point me some directions?
public InputStream getInputStream() throws IOException {
PipedInputStream in = new PipedInputStream();
PipedOutputStream out = new PipedOutputStream(in);
Thread t = new Thread(new Runnable() {
public void run () {
try {
save(out); // this save method can throw IOException
} catch (IOException e) {
throw new RuntimeException("Failed to save entries to output stream", e);
}
}
});
t.start();
return in;
}
private void save(OutputStream out) throws IOException {...}
I have read How to catch an Exception from a thread but felt my question is still different,
because I want to re-throw the exception in parent thread, the question above solves the problem that catches the exception only
But my question here is, the save method could throw IOException, and I would like to catch that and re-throw that as part of this getInputStream method.
You can't do that, because an exception can be raised in the background thread executing save() long after getInputStream() returns.
If save() can throw an exception for some reason other than an IOException from its PipedOutputStream, and you want to convey some information about that failure to the thread that is reading from the PipedInputStream, submitting a Callable to an ExecutorService is probably the right approach. An example of this case would be that save() queries a database, and writes the results to a stream; if query fails, you want to log that SQLException in the thread that is reading that stream. The reading thread could read the PipedInputStream, and then check the Future it received from submitting the task to the ExecutorService to see if it completed abnormally.
But if you don't need any information from the exception thrown by save(), and just want to throw an exception in the thread reading from the corresponding PipedInputStream, simply let the background thread die. This will raise a "broken pipe" IOException in the main thread when it attempts to read from its PipedInputStream.
While all the comments that lead to uncaught exception handler and similar stuff are correct, I would like to post this answer as an alternative.
You can use an ExecutorService which will return you a Future and then you can catch ExecutionException when getting the result, something like this (typing directly here, might need some validation):
ExecutorService pool = Executors.newFixedThreadPool(1);
Future result = pool.submit(this::save);
result.get(); // will throw ExecutionException

Stopping a Thread / Threads calls interrupt on itself after crash?

I am currently running a Thread from a Service to do some background work.
Now there is the possibility that the Thread crashes or I want to
interrupt the thread from the Service. So how am I supposed to:
stop the Thread realiable, (hard)
catch exceptions and call the Service about the crash
handle InterruptedException if interrupted while sleep()
is Thread.isInterrupted a good way to detect if the Thread stopped?
What I have done so far is the following:
#Override
public void run() {
try {
while (!Thread.currentThread().isInterrupted()) {
doMyBackgroundWork();
sleep();
}
}catch(Exception e){
ExceptionHandler.logAndSendException(e);
Thread.currentThread().interrupt();
if(crashedListener != null){
crashedListener.onThreadCrashed();
}
}
LOG.i("Thread stops now.");
}
private void sleep() {
try {
sleep(frequency);
} catch (InterruptedException e) {
//what to do here? it can happen because I stopped it myself
}
}
So at first I am running my Thread until it gets interrupted.
If any exception occurs, I want to start a new Thread, therefore
my Service implements a listener interface and I call it, once an
Exception is thrown. I know that catching everything is discouraged,
but I need to know if the Thread stops, without polling Thread.isAlive()
all the time.
Additionally to my four questions above:
is my code reliable and does what I need?
is it ok to call interrupt on the Thread itself?
Thanks!
You are not actually interrupting your own thread because the catch block is outside of the while loop. Therefore, any exception would stop execution immediately.
Interruption is essentially just a request (usually from another thread) to stop doing what you are doing. The thread is free to ignore it and keep doing what it is doing. Normally you have to throw an exception in response to an interrupt, or stop execution some other way such as just breaking from the loop (you need this around the //what to do here? comment). It so happens that some library methods are "responsive to interruption" meaning they will throw an exception if the thread is ever interrupted, such as Thread.sleep(), which you will most likely have in your sleep call.
I recommend picking Java Concurrency In Practice. Among the excellent concurrency material, there is a chapter on interrupts which is very helpful.
EDIT:
I would remove the code where you interrupt your own thread. You will also need to rethrow the InterruptedException as a runtime exception to get out of the execution loop. Usually people will create a new Exception that extends RuntimeException that is something like MyInterruptedException. You can then add it to the catch block around your loop so that you know when the thread was interrupted vs execution failed.
As a general example you can do something like this:
public void run() {
try {
while (true) {
// check for interrupts in the loop, or somewhere in the work method
if (Thread.interrupted()) {
throw new MyInterruptedException("Important thread interrupted.");
}
doMyBackgroundWork();
sleep();
}
}
catch(Exception e){
ExceptionHandler.logAndSendException(e);
if(crashedListener != null){
crashedListener.onThreadCrashed();
}
}
catch(MyInterruptedException i) {
LOG.i("Execution stopping because of interrupt.");
}
}
private void sleep() {
try {
sleep(frequency);
} catch (InterruptedException e) {
throw new MyInterrptedException(e);
}
}
we have a nice and effective method called stop()(Thread.stop(void):void) which is deprecated, but it works and it's lovely.
Note that stop() throws ThreadDeath at the target thread which is not an exception(and it could any other throwable too), but an Error, so your code will not catch any signal about this.
public void run() {
try {
while (<<using_a_volatile_bool_type_is_better>>) {
...
}
}catch(Throwable t){/**/}/*use throwable instead of exception.*/}
}
Beside dear friend stop() we also have pause() method too, and it really pauses the target thread.
Not just one solution out there, but if it's really critical to keep thread run and run the emergency(or itself) just after any crash, you may run it as a separately app/process, plus get progress status(if any) that ensures you the target thread/app is not freezed(blocked,...)

Should I Thread.currentThread.interrupt() before I throw an exception back?

I am implementing an interface which throws IOException. In my implementation, I call another method which can block, and therefore throw InterruptedException.
Context:
I want to end the treatment if I am interrupted;
this is not a thread I created myself.
My current idea is to do as such (skeleton code):
#Override
public void implementedMethod()
throws IOException
{
try {
methodThatBlocks();
} catch (InterruptedException ignored) {
Thread.currentThread().interrupt();
throw new IOException();
}
}
is that the correct way? Or should I just throw and not .interrupt()?
Yes, you should call interrupt() to let the calling code know that the thread has been interrupted. If you don't do it, since the InterruptedException clears it, the calling code will have no way to know about the interruption and won't stop running although it should.
Let me quote Java Concurrency in Practice:
Restore the interrupt. Sometimes you cannot throw InterruptedException, for instance when your code is part of a Runnable. In these situations, you must catch InterruptedException and restore the interrupted status by calling interrupt on the current thread, so that code higher up the call stack can see that an interrupt was issued,
as demonstrated in Listing 5.10.
public class TaskRunnable implements Runnable {
BlockingQueue<Task> queue;
...
public void run() {
try {
processTask(queue.take());
} catch (InterruptedException e) {
// restore interrupted status
Thread.currentThread().interrupt();
}
}
}
Of course not. The thread is already unblocked and running. In the code that is about to throw an exception. What would be the point?

In which case the try catch is bypassed in java?

I managed to bypass the try catch block,
by nesting multiple threads.
Is therere some rule, where it is documented, when the try catch block is bypassed by Exceptions?
try{
Runnable r = new Runnable() {
#Override
public void run() {
System.out.println("Thread");
Display.getDefault().syncExec(new Runnable() {
#Override
public void run() {
System.out.println("ThreadGUI");
throw new NullPointerException();
}
});
}
};
Thread t = new Thread(r);
t.start();
} catch(NullPointerException e) {
//nothing
}
System.out.println("Ende");
Exceptions don't automatically propagate across thread boundaries. If you throw an exception in a particular thread, you can only catch it in that thread. The lexical structure of your code makes no difference in this respect.
The following are the relevant parts of the JLS:
During the process of throwing an exception, the Java virtual machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process continues until a handler is found that indicates that it handles that particular exception by naming the class of the exception or a superclass of the class of the exception (§11.2). If no such handler is found, then the exception may be handled by one of a hierarchy of uncaught exception handlers (§11.3) - thus every effort is made to avoid letting an exception go unhandled.
...
If no catch clause that can handle an exception can be found, then the current thread (the thread that encountered the exception) is terminated.
Your exception is thrown out in a different thread. This is why it is not caught. You might want to catch it inside tyour new thread and somehow propagate it to the main one.

Calling Thread.sleep() with *interrupted status* set?

The Java documentation is not clear on this point. What happens if you call interrupt on a Thread before a call to Thread.sleep():
//interrupt reaches Thread here
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
return;
}
Will the InterruptedException be thrown?
Please point to relevant documentation.
Yes, it will throw an exception. According to the javadoc for Thread.sleep, the method:
Throws:
InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.
The 'has' in this case is an informal way of referring to the interrupted status. It's a shame that it is informal - if there's somewhere a spec should be precise and unambiguous, well, it's everywhere, but it's the threading primitives above all.
The way the interrupted status mechanism works in general is if that a thread receives an interruption while it's not interruptible (because it's running), then the interruption is essentially made to wait until the thread is interrupted, at which point it swoops in an causes an InterruptedException. This is an example of that mechanism.
A thread can be interrupted at any point in time, but it won't have any effect until that thread specifically checks its interrupted state with Thread.currentThread().isInterrupted() or when it reaches, or is already blocked by a call to Thread.sleep(long), Object.wait(long) or other standard JDK methods which throw InterruptedException such as those in the java.nio package. The thread's interrupt status is reset when you catch an InterruptedException or when you explicitly call Thread.interrupted() (see the documentation for that elusive method).
This JavaSpecialists article should explain a bit more about how thread interrupts work and how to deal with them properly.
You can use the following class to test the behavior. In this case, the loop is not interrupted and the thread dies when it gets to the sleep.
public class TestInterrupt{
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(){
public void run(){
System.out.println("hello");
try {
for (int i = 0 ; i < 1000000; i++){
System.out.print(".");
}
Thread.sleep(10000);
} catch (InterruptedException e) {
System.out.println("interrupted");
e.printStackTrace();
}
}
};
t.start();
Thread.sleep(100);
System.out.println("about to interrupt.");
t.interrupt();
}
}
The docs of InterruptedException seems to suggest that it can be interrupted at other times
http://download.oracle.com/javase/1.4.2/docs/api/java/lang/InterruptedException.html
Thrown when a thread is waiting, sleeping, or otherwise paused for a long time and another thread interrupts it using the interrupt method in class Thread
Also since it is a checked exception, it will only be thrown by methods that declare it. See
http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Thread.html#interrupt()

Categories