Exceptions in Constructors
Say if two constructors throw exceptions, then the compiler calls terminate()... meaning it doesnt know what to do..
The pity fact is that I am not able to understand why the compiler is not able to handle
Is it because while looping up, that is, while bubling through the class hierarchy while destruction, it is possible that the two different exceptions could lead to two different catch blocks and the compiler doesnt know which one to choose??
If i am not rite.. please do give me the correct explanation
The pity fact is that I am not able to understand why the compiler is not able to handle
Is it because while looping up, that is, while bubling through the class hierarchy while destruction, it is possible that the two different exceptions could lead to two different catch blocks and the compiler doesnt know which one to choose??
If i am not rite.. please do give me the correct explanation
Ok, that section doesn't help answer the question.
I think the question OP is trying to ask is why C++ does not handle exceptions that are thrown while stack unwinding
[a previous exception].
The purpose of stack unwinding is to run destructors of objects so that, at the point of the matching catch(), the
program is in a coherent state, with no memory leaks. This last part requires a lot of help from the programmer
in the form of catch() blocks, which serve not only to ensure there are no memory leaks but also to "clean up".
For example, it might have to roll back a database transaction.
If an exception occurs inside a catch() block, or while C++ is performing the stack unwinding of a previous exception,
then some of the cleanup work for that exception isn't going to happen, since execution immediately stops so that
stack unwinding can begin. This therefore would leave the program in a potentially incoherent state, possibly with
memory leaks since the catch() block did not finish. All this means that as a programmer, you have no real hope of
restoring your program to a coherent state in the second catch() block, and therefore it was decided to have the
second exception just call std::terminate().
Since one of the purposes of stack unwinding is to call object destructors, this is why it is not recommended ever
to throw in a destructor (or at least allow an exception to escape a destructor) -- you leave yourself open to
getting aborted as a result of a double exception.
I think the question OP is trying to ask is why C++ does not handle exceptions that are thrown while stack unwinding
[a previous exception].
The purpose of stack unwinding is to run destructors of objects so that, at the point of the matching catch(), the
program is in a coherent state, with no memory leaks. This last part requires a lot of help from the programmer
in the form of catch() blocks, which serve not only to ensure there are no memory leaks but also to "clean up".
For example, it might have to roll back a database transaction.
If an exception occurs inside a catch() block, or while C++ is performing the stack unwinding of a previous exception,
then some of the cleanup work for that exception isn't going to happen, since execution immediately stops so that
stack unwinding can begin. This therefore would leave the program in a potentially incoherent state, possibly with
memory leaks since the catch() block did not finish. All this means that as a programmer, you have no real hope of
restoring your program to a coherent state in the second catch() block, and therefore it was decided to have the
second exception just call std::terminate().
Since one of the purposes of stack unwinding is to call object destructors, this is why it is not recommended ever
to throw in a destructor (or at least allow an exception to escape a destructor) -- you leave yourself open to
getting aborted as a result of a double exception.
Topic archived. No new replies allowed.