What does it mean when the error doesn't crash the program
Sometimes Eclipse comes up saying "hey you gotta debug this line !!!" but does not actually close the program. Then I can keep playing the big two and even go through the same events that caused the error the first time and get another error window!
The error is simple, I'll fix it, I just want to know why some errors are terminal and some are not? Who cares?
source to share
Programming errors can be classified into the following categories:
- Compilation errors that are caught by the compiler at compile time and without fixing them cannot run the program at all.
- Runtime errors that are not caught by the compiler but put the computer in a situation where it cannot figure out what to do on its own, such as unhandled exceptions. In most cases this will cause the program to crash at runtime and crash.
- Logical errors that are perfectly acceptable for a computer because it is a valid computer program, but do not produce the expected result. The computer cannot catch them because the computer does not know your intention.
In practice, it is good for bugs to become as deadly as possible as soon as they arise. This forces us to find them earlier and make them easier. This is why, in "safe" languages like Java, we checked for exceptions, and unhandled exceptions will cause the application to crash immediately, instead of going further and probably producing incorrect results.
source to share
I would guess that in your case it's all about which thread the Exception occurred on (your app is a graphical app, right?). If an exception occurs on the main thread, it may be terminal, but if it occurs on another thread, it is not terminal. This is the terminal for the main thread if the other threads in the application are daemon threads. When threads are daemons, the application will terminate before they finish, regardless of their status. If they are not daemons, the application will wait until they complete.
I don't know the Eclipse framework very well, but I think it can handle the exception in the GUI thread.
I have included a sample java application to illustrate my example;
public class ThreadTest {
public static void main(String[] args) {
Runnable test = new Runnable() {
public void run() {
try {
System.out.println("Sleeping");
Thread.sleep(5000);
System.out.println("Slept");
} catch (InterruptedException e) {
}
}
};
Thread t = new Thread(test);
//t.setDaemon(true);
t.start();
System.out.println("Waiting to fail");
throw new RuntimeException("Error");
}
}
You will see a difference in behavior if not tied to the t.setDaemon (true) line.
source to share
The previous answer gets the java part of this right:
If the exception happens on your main thread, it may be Terminal, but if it happens on another thread, it is not Terminal. This is the terminal for the main one if the other threads in the application are daemon threads.
The big truth is that the JVM your application is running in will shutdown if there are no non-daemon threads still running. It is either an explicit call to System.exit (or an outright JVM crash) - these are the only paths that completely uninstall the JVM.
In many simpler Java applications, there is only one thread without a daemon (the thread with which the JVM started to run your main () at startup.) Since in the simple case, the thread running our code is the only non-daemon thread, it seems like an unhandled exception causes the JVM to exit. This is not true, unless this thread is the only remaining non-demon.
You can prove it with the following small program:
public class TestMain {
public static void main(String[] args) {
Thread t1 = new Thread() {
public void run() {
while(true) {
System.out.println("A");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
System.out.println("t1 interrupted.");
}
}
}
};
t1.setDaemon(false);
Thread t2 = new Thread() {
public void run() {
int count = 0;
while(true) {
if(count < 5) {
System.out.println("B");
count++;
} else {
throw new RuntimeException("Intentional RuntimeException!");
}
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
System.out.println("t2 interrupted.");
}
}
}
};
t2.setDaemon(false);
t1.start();
t2.start();
}
}
If you run this, you will notice that you will get mixed "A" and "B" up to 5th "B", after which you will get the stack trace except we chose "Continue" ("B" does not continue, because this thread just died due to an unhandled exception.)
Now if you go back and change t1.setDaemon(false)
to t1.setDaemon(true)
and run again, you will see that when t2 exits due to an exception, there is no non-daemon remaining and the JVM will exit.
This answers the question "why some errors do not close the JVM". But that doesn't answer the question of why Eclipse is popping up the debugger.
The answer to this is simpler (but I'm a little less sure about this ... someone else is calling): The Eclipse debugger pauses any time the thread dies due to an unhandled exception. This makes the assumption that you didn't mean the thread is dying and that you need to fix the error. I believe it does observe the java.lang.ThreadDeath exception and suspends it at any time.
source to share