Stack unwinding

[George2]

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:

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

Scenario 2:

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

Scenario 3:

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

Scenario 4:

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

thanks in advance,
George

 

[Barry]

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:

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

Scenario 2:

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

Scenario 3:

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

Scenario 4:

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

Every local object has a scope,
(I)after when the scope reaches the end, the local objects in the scope
got destructed. (II)If exception thrown, then the local objects in the
scope before the throwing got destructed.

scenario 1 and 2, try block creates a scope with the pair of
parenthesis. it's the same as (II)

scenario 2 and 4, "not catched" is better to be "not handled", as you
already have catch(...) handler (I added ... here). So in scenario 4,
you can simply ignore the try/catch, and it goes like (I)

 

[James Kanze]

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:

try {
local object defined;
exception throws;
} catch () {
catched;[/QUOTE]
(BTW: the past participle of "to catch" is caught, not catched.)[QUOTE]
}[/QUOTE]

Whether you catch the exception or not, the exception leaves the
block in which the objects were defined, so they are destructed.
[QUOTE]

Scenario 2:

try {
local object defined;
exception throws;
} catch () {
not catched;
}[/QUOTE]

I don't see where this is any different than the first scenario.
Or do you mean to imply that in the catch didn't apply to the
type thrown?  Either way, it doesn't make a difference.  The
exception causes the block to be exited, so destructors are
called.
[QUOTE]

Scenario 3:

local object defined;
try{
exception throws;
} catch () {
catched;
}[/QUOTE]

Here, the local objects are not in the block, and the exception
doesn't propagate any further, so they are not destructed.

It's actually fairly easy to understand, and very intuitive.  If
you execute code where the variables are visible, then they
haven't been destructed.  If you don't, then they have.  Here,
for example, you can add code behind the catch clause which can
use the local object defined before the try, so the objects
can't be destructed.  Objects defined in the try block, however,
are not visible in code after the catch clause (or code in the
catch clause), so will have been destructed.
[QUOTE]

Scenario 4:

local object defined;
try{
exception throws;
} catch () {
not catched;
}[/QUOTE]

If the exception is not caught, it propagates upward, leaving
additional local blocks.  The destructors are called for any
objects defined in those blocks.

Again, it's a question of whether the objects will be visible or
not.  If the catch() clause doesn't catch the exception, then
the code behind it will not be executed, and any variables that
would have been visible there, but will not be visible when the
exception is finally caught, will be destructed.
[QUOTE]