How does unhandled exceptions affect JVM?

Question

My project got like 20 unhandled exceptions, doesn't matter why, and I was wondering how do they affect the JVM? It doesn't crash, but I'm still wondering what are their footprint in JVM. Where do they go?

Answer 1

The JVM is completely unaffected by uncaught exceptions. It will usually kill the thread, though not always. In the case of the EventQueue, a single event terminates abnormally but the events keep coming.

Uncaught exceptions are not good. If you are getting 20 unhandled exceptions and have no other problems, you can improve your program's performance by getting rid of the code and the threads that produce them; they are obviously not doing anything that needs doing (at least from the line that produced the exception on).

The biggest problem I have had with uncaught exceptions is that they destabilize the program. One field gets a bad number, later calculations (in other threads or events) use that bad number, and things go downhill from there. Sometimes the program recovers--which is nice in a demo--and sometimes it slowly gets worse and worse--which in a demo is worse than an abnormal termination. Often the stack trace cannot be seen. Even when it should be obvious, I have known testers and users to be unable to see it until they have called me, I have figured out what must have happened, and told them to look for it. ("Oh yeah, here it is under my Solitaire game. Sorry if I said it definitely had not displayed any messages. 'NullPointerException'. Does that mean anything?")

Unnoticed exceptions usually look like a minor bug in the calculations. I've wasted a lot of time checking for typos in my code. Only when I've become convinced that there was no way the program could do what it did did it dawn on me there was an uncaught exception. Also, these bugs can be very tricky to reproduce; the program becomes demented, but in a different place and in different ways. (Keep your system output on top of your Solitaire game and all your debugging problems go away.)

With Java 1.5, there is a new method, Thread.setDefaultUncaughtExceptionHandler, which lets you kill the program or otherwise deal with this menace. Using lots of try/catch blocks can give you better control (if you want it) and was the only way (I knew of) to deal with this before 1.5.

Answer 2

Every thread has something called an UncaughtExceptionHandler. Whenever you have a stray exception not caught by anyone, the Thread's UncaughtExceptionHandler's uncaughtException method is invoked. Generally the thread would terminate on unhandled exceptions.

I dont think, there is much to think of performance for unhandled exceptions vs handled excpetions, as the only major performance issue with exception is filling in the stack-trace, which is done during the creation of Exception itself(constructor ends up calling fillInStackTrace()). If unhandled exceptions means lesser try-catch blocks(if its so in your case), then you can think from the perspective that try-catches are generally expensive.

Answer 3

Any uncaught Throwable (Runtime Exception or Error) will kill the thread in which the throwable was thrown. When there are no (non daemon) threads left the JVM process will exit.

If you run your code on top of a good thread pool mechanism, the thread pool will detect that a worker thread died and will create a fresh worker thread in it's place. I personally believe that you should not catch Throwable, but instead catch Runtime Exceptions.

Answer 4

All exception are handled either by your code or by the "uncaught exception handler" The only way to avoid handling an exception is to return from a finally block or exiting the program.

An unhandled exception/error will result in the end of the running thread. However it this is acceptable response, there is no reason this needs to upset your application.

One problem with Exceptions is they have some overhead and if you create excessive numbers of them it can hurt performance.