Re: exception handling, function call and memory
On Jan 30, 11:32 am, "Alf P. Steinbach" <al...@start.no> wrote:
* George2:
Such code segment is used to check whether function call or
exception- handling mechanism runs out of memory first
(written by Bjarne),
[Code]
void perverted()
{
try{
throw exception();
}
catch (exception& e)
{
perverted();
cout << e.what() << endl;
}
}
[/Code]
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.
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.)
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.
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.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34