By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,267 Members | 1,808 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,267 IT Pros & Developers. It's quick & easy.

exception handling, function call and memory

P: n/a
Hello everyone,
Such code segment is used to check whether function call or exception-
handling mechanism runs out of memory first (written by Bjarne),

Expand|Select|Wrap|Line Numbers
  1. void perverted()
  2. {
  3. try{
  4. throw exception();
  5. }
  6. catch (exception& e)
  7. {
  8. perverted();
  9. cout << e.what() << endl;
  10. }
  11. }
  12.  
  13.  
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
Jan 30 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
On Jan 30, 11:32 am, "Alf P. Steinbach" <al...@start.nowrote:
* George2:
Such code segment is used to check whether function call or
exception- handling mechanism runs out of memory first
(written by Bjarne),
Expand|Select|Wrap|Line Numbers
  1.  void perverted()
  2.  {
  3.      try{
  4.          throw exception();
  5.      }
  6.      catch (exception& e)
  7.      {
  8.          perverted();
  9.          cout << e.what() << endl;
  10.      }
  11.  }
Expand|Select|Wrap|Line Numbers
  1.  
  2.         
  3.                         
  4.  
  5.  
  6.  
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jan 31 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.