Where are exceptions stored ? Stack, Heap. How is memory allocated and deallocated for Exceptions? Now if you have more than one exception which needs to be handled are there objects of all these exceptions created?
I would assume that memory for exceptions is allocated the same way as for all other objects (on the heap).
This used to be a problem, because then you cannot allocate memory for an OutOfMemoryError, which is why there was no stack trace until Java 1.6. Now they pre-allocate space for the stacktrace as well.
If you are wondering where the reference to the exception is stored while it is being thrown, the JVM keeps the reference internally while it unwinds the call stack to find the exception handler, who then gets the reference (on its stack frame, just like any other local variable).
There cannot be two exceptions being thrown at the same time (on the same thread). They can be nested, but then you have only one "active" exception with a reference to the nested exception.
When all references to the exception disappear (e.g. after the exception handler is finished), the exception gets garbage-collected like everything else.
Exceptions in Java are objects, and as such, they are stored on the heap.
When an exception is thrown, the JVM looks for a matching exception handler in the code. This applies even when there are multiple exceptions that something could throw.
Where are exceptions stored ? Stack, Heap. How is memory allocated and deallocated for Exceptions?
Exceptions are objects like any other in this regard. Allocated on the heap via new
, deallocated by the garbage collector.
Now if you have more than one exception which needs to be handled are there objects of all these exceptions created?
Not sure what you mean with this. They're created via new
, one at a time. There can be more than one around when you use exception chaining - and there's actually nothing keeping you from creating thousands of exceptions and putting them in a List somewhere - it just doesn't make much sense.
I got this link but still am not satisfied with it. http://www.devx.com/tips/Tip/13754
For the most complete information on exceptions, we can go directly to the source: Chapter 11: Exceptions of The Java Language Specification, Second Edition.
Exceptions are indeed objects. They are a subclass of Throwable
:
Every exception is represented by an instance of the class Throwable or one of its subclasses; such an object can be used to carry information from the point at which an exception occurs to the handler that catches it.
Therefore, it would probably be safe to assume, that as with any other Object
in Java, it will be allocated on the heap.
In terms of having mulitple Exception
objects, that probably wouldn't be the case, as once an exception occurs, the Java Virtual Machine will start to find an exception handler.
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.
For more information on how exceptions are to be handled at runtime, Section 11.3 Handling of an Exception has the details.
For C++ it's not defined where to store exceptions, but most compilers use a special stack. For Java as somebody wrote before, they're stored on the heap.
As exceptions are objects in C++ as well as in Java, they're allocated and deallocated as objects in the specific language.
There is always only one exception active per thread in both languages.
In Java, Exception extends Throwable which extends Object. i.e. from a memory point of view its an object just like any other.
It has been suggested in Java 7 that local variables could be placed on the stack using escape analysis to find candidates for stack variables. However, Exceptions are typically thrown from a method to a caller (or its caller etc.) so its wouldn't be very useful placing the Exception on the stack.