Stack unwinding

Hello everyone,


I listed for scenarios. I think case 1, 2 and 4 are object's destructor is called during stack unwinding caused by exception. Scenario 3 is not stack unwinding and it is normal function return (not exception) triggers the destructor of the object.

Scenario 1:

Code:

---

try{
    local object defined;
    exception throws;
} catch ()
{
    catched;
}

---

Scenario 2:

Code:

---

try{
    local object defined;
    exception throws;
} catch ()
{
    not catched;
}

---

Scenario 3:

Code:

---

    local object defined;
try{
    exception throws;
} catch ()
{
    catched;
}

---

Scenario 4:

Code:

---

    local object defined;
try{
    exception throws;
} catch ()
{
    not catched;
}

---

thanks in advance,
George

I think the simple rule is that local objects are destructed when they leave scope - one way or another.

In example 3, unless the catch block rethrows, the local object does not indeed exit its scope within that snippet.

I don't think this example has much to do with exceptions. It's just simple object scope. Normal variables declared inside a set of braces are deleted once they reach the matching closing brace.

However, if the exception is never caught, the program will crash.

Quote:

---

Originally Posted by Elysia

However, if the exception is never caught, the program will crash.

---

Is "Crash" the right term to use when your stack completely unwinds because of an uncaught exception? It certainly looks like a crash, but there must be a different term for it?

How about "abort"? I think abort() gets called anyway for the default uncaught exception handler . . . . Or "terminate". Or "die". :p

Terminate gets, called. The default termination behavior is to call abort, but it is possible to change that.

Crash is not the term for it, since the behavior is perfectly defined, and sometimes desirable. For example, there may be no reasonable way to handle a bad_alloc exception, so the right thing to do is just kill the terminate.

I wonder if it is in the standard, but I seem to recall it mentioned, that if an exception is uncaught, the destruction of local obects is not guaranteed?

Actually MingW doesn't output "~A()" for this code (or is it wrong?), so there might be more in George2's question.

Code:

---

#include <iostream>

struct A
{
    A() {std::cout << "A()\n"; }
    ~A() { std::cout << "~A()\n"; }
};

int main()
{
    A a;
    throw 1;
}

---

That's correct, anon. It's implementation-defined whether the stack is actually unwound for an uncaught exception.

Thanks. So the fix is to do a catch-all on the highest level?

Well, since exceptions can be caught at any level, the compiler needs to unwind the stack until a catch is encountered, does it not?

No. There are many possible implementations of exception handling. One possible implementation would have a separate try block stack. Every time the program enters a try block, information about the catchers of this block is pushed on this stack. Every time an object is created, information about its destructor is pushed on this stack, or perhaps yet another stack. When an exception is thrown, this stack is searched for a handler. If none is found, the program terminates. If an appropriate handler is found, the program then uses the destructor information to destruct objects that need it. Finally, it restores the state of the registers and jumps directly to the catch block.

Not a very efficient way, but good when the machine can have unexpected stack content. In particular, this method works when you call back and forth between C++ and a language that uses the stack very differently. It's also good if you have rather a lot of RAM but very little space for programs, because other unwinding methods need a lot of static information. This method uses more dynamic information.

Anyway, it's definitely possible.

Thanks CornedBee,


Great reply!

Two more comments,

1.

Quote:

---

Originally Posted by CornedBee

If an appropriate handler is found, the program then uses the destructor information to destruct objects that need it. Finally, it restores the state of the registers and jumps directly to the catch block.

---

So invoking destructor before invoking catch handler, right?

2.

Quote:

---

Originally Posted by CornedBee

Not a very efficient way, but good when the machine can have unexpected stack content. In particular, this method works when you call back and forth between C++ and a language that uses the stack very differently. It's also good if you have rather a lot of RAM but very little space for programs, because other unwinding methods need a lot of static information. This method uses more dynamic information.

---

What do you mean "good when the machine can have unexpected stack content"?


regards,
George

Quote:

---

Originally Posted by George2

So invoking destructor before invoking catch handler, right?

---

Yes, that part is required by the standard. By the time the catch handler is entered, the stack must have been unwound.

Quote:

---

What do you mean "good when the machine can have unexpected stack content"?

---

Not all computers have hardware support for the stack. On such systems, a language like C++ might emulate this by some other means. And a different language might emulate it differently. If you then add calls back and forth between the two languages, the stack will look strange, and it won't really be possible to trace execution through it.

You have to remember that C and C++ were designed to be implementable on very esoteric systems. Thus, in many cases the exact behaviour is left to the implementation even when it seems completely obvious how it's to be done.

Thanks for your description, CornedBee!


My question is answered.

Quote:

---

Originally Posted by CornedBee

Yes, that part is required by the standard. By the time the catch handler is entered, the stack must have been unwound.


Not all computers have hardware support for the stack. On such systems, a language like C++ might emulate this by some other means. And a different language might emulate it differently. If you then add calls back and forth between the two languages, the stack will look strange, and it won't really be possible to trace execution through it.

You have to remember that C and C++ were designed to be implementable on very esoteric systems. Thus, in many cases the exact behaviour is left to the implementation even when it seems completely obvious how it's to be done.

---

regards,
George