exception handling, function call and memory

[George2]

Hello everyone,


Such code segment is used to check whether function call or exception-
handling mechanism runs out of memory first (written by Bjarne),

void perverted()
{
    try{
        throw exception();
    }
    catch (exception& e)
    {
        perverted();
        cout << e.what() << endl;
    }
}

1.

My question is when the exception is thrown, and goes to exception
handler in catch block, it will do operations in the following
sequences,

(1) execute the exception handler code (since there will be recursive
function call -- stack will ever increasing);
(2) unwind stack.

Runs out of memory because function call will make stack ever-
increasing, right?

If it does (2) before (1), I think stack will always be unwinded
before exception handling is called -- then stack will never grow, so
there will be no out-of-memory caused by an ever increasing stack.

Is that correct?

2.

I am confused about why exception handling mechanism will run out of
memory because in exception handle implementation, we just insert
exception handler registration block of the function onto the
beginning of the new function call stack each time there is a function
call, so the memory should be the memory consumed by function call
stuff, I do not think exception handling mechanism itself will consume
additional memory. How do you think of it and how do you think of the
what are the memory consumed by exception handling mechanism?


thanks in advance,
George

 

[Alf P. Steinbach]

* George2:

Such code segment is used to check whether function call or exception-
handling mechanism runs out of memory first (written by Bjarne),

void perverted()
{
try{
throw exception();
}
catch (exception& e)
{
perverted();
cout << e.what() << endl;
}
}

1.

My question is when the exception is thrown, and goes to exception
handler in catch block, it will do operations in the following
sequences,

(1) execute the exception handler code (since there will be recursive
function call -- stack will ever increasing);
(2) unwind stack.

From the C++ view, ignoring details of how exception handling is
implemented at the machine code level (e.g. double stack walk), a
'throw' results in stack unwinding followed by execution of 'catch'
code, if there is a matching 'catch'.

Runs out of memory because function call will make stack ever-
increasing, right?

From an academic point of view that depends on optimization. A
compiler could conceivably detect that the above is an infinite
recursion doing nothing. In practice it will run out of memory.

If it does (2) before (1), I think stack will always be unwinded
before exception handling is called -- then stack will never grow, so
there will be no out-of-memory caused by an ever increasing stack.

Is that correct?

No. In the code above the "stack unwinding" is only locally within the
function call, essentially doing nothing, not back to a call of the
function.

2.

I am confused about why exception handling mechanism will run out of
memory because in exception handle implementation, we just insert
exception handler registration block of the function onto the
beginning of the new function call stack each time there is a function
call, so the memory should be the memory consumed by function call
stuff, I do not think exception handling mechanism itself will consume
additional memory. How do you think of it and how do you think of the
what are the memory consumed by exception handling mechanism?

Whether a 'try' consumes memory depends on the implementation.


Cheers, & hth.,

- Alf

PS: George, could you please start giving references for your quotes and
parahprases, and also, please start reading the groups you post to.

 

[Andre Kostur]

Hello everyone,


Such code segment is used to check whether function call or exception-
handling mechanism runs out of memory first (written by Bjarne),

void perverted()
{
try{
throw exception();
}
catch (exception& e)
{
perverted();
cout << e.what() << endl;
}
}

1.

My question is when the exception is thrown, and goes to exception
handler in catch block, it will do operations in the following
sequences,

(1) execute the exception handler code (since there will be recursive
function call -- stack will ever increasing);
(2) unwind stack.

Not entirely true. The stack inside the try {} block is unwound first,
then the catch clause is executed.

Runs out of memory because function call will make stack ever-
increasing, right?

Yep. Infinite recursion.

If it does (2) before (1), I think stack will always be unwinded
before exception handling is called -- then stack will never grow, so
there will be no out-of-memory caused by an ever increasing stack.

Nope. Somebody calls perverted. Let's call that stack frame (OK, let's
assume your implementation uses stack frames) perverted[1]. In that
invocation the exception is thrown, which will also be caught in the
same invocation. So perverted[1] is still on the stack. The actual
perverted[1] frame cannot be unwound as there may be more stuff
happening after the catch clause. The catch clause then calls perverted
[2]. Which throws, goes into the catch clause, calls perverted[3],
rinse, lather, repeat.

Is that correct?

2.

I am confused about why exception handling mechanism will run out of
memory because in exception handle implementation, we just insert
exception handler registration block of the function onto the
beginning of the new function call stack each time there is a function
call, so the memory should be the memory consumed by function call
stuff, I do not think exception handling mechanism itself will consume
additional memory. How do you think of it and how do you think of the
what are the memory consumed by exception handling mechanism?

Come to think of it, there's another chunk of memory hanging around that
the exeception object itself needs to occupy. Other than that, I'm not
sure I understand what your question is in this part.

 

[James Kanze]

* George2:

Such code segment is used to check whether function call or
exception- handling mechanism runs out of memory first
(written by Bjarne),

void perverted()
{
try{
throw exception();
}
catch (exception& e)
{
perverted();
cout << e.what() << endl;
}
}

1.
My question is when the exception is thrown, and goes to exception
handler in catch block, it will do operations in the following
sequences,
(1) execute the exception handler code (since there will be recursive
function call -- stack will ever increasing);
(2) unwind stack.

From the C++ view, ignoring details of how exception handling
is implemented at the machine code level (e.g. double stack
walk), a 'throw' results in stack unwinding followed by
execution of 'catch' code, if there is a matching 'catch'.

From an academic point of view that depends on optimization. A
compiler could conceivably detect that the above is an infinite
recursion doing nothing. In practice it will run out of memory.

No. In the code above the "stack unwinding" is only locally
within the function call, essentially doing nothing, not back
to a call of the function.

I'm not sure that that was the point of the example, however.
(It's a lot easier to get infinite recursion.) The point
here, I think, is that the exception cannot be destructed before
the catch clause which handles it has finished. And in the
meantime, another exception is raised. The compiler cannot use
static memory for the exception itself---it must use some sort
of stack-like mechanism. And code like the above will cause
this "exception stack" to overflow. (On the machines I usually
work on, this exception stack will overflow long before you'd
get normal stack overflow.)

Whether a 'try' consumes memory depends on the implementation.

Whether the try consumes memory or not, the thrown exceptions
certainly will.

PS: George, could you please start giving references for your
quotes and parahprases, and also, please start reading the
groups you post to.

Will all people not present please step forward. (I know.
It's frustrating me, too.)