Thread: exception handling, function call and memory

Thanks Mats,


Sorry I missed this reply from you after reviewing this thread again. :-)

(1) I think you mean even if we do stack unwinding at first, there is still something left on the current stack of the function, like return address?

(2) Then exception handler will be called.

So, the conclusion is stack will continue to grow because of (1). Maybe also because of (2), caller will push something on stack? I missed something in assembly language about how function call is implemented in details. :-)

Originally Posted by matsp

My comment was to clarify your question on CornedBee's 1,2,3 ordering, and I agree with CornedBee that it happens in the order described.

But the stack will possibly, temporarily, grow when performing exception handling BEFORE it shrinks. In the example given in the #1 post here, there will be no (large) stack reduction, because the throw does not lead to leaving the function, so there is no other stack-frame to remove.

--
Mats

regards,
George

Thanks Elysia,


Great! My question is answered.

Originally Posted by Elysia

Yes, everything in the try block, including function calls, objects and other variables will be destroyed, poped or just disappear, because they go out of scope. Everything before the try block will remain intact.
A way to look at exceptions is this:
For each function, the compiler will use a "return" statement, so the local variables are poped, destructors are called, etc, until it reaches the function that handles the exception. There it will jump to the catch handler and that means everything in the try block goes out of scope, so variables are poped and destructors are called.



You don't.

Code:

void Help2(int& n)
{
	n = 7;
	throw 1;
}

void Help()
{
	int n = 0;
	try
	{
		Help2(n);
	}
	catch(...)
	{
		cout << n << endl;
	}
}

In the catch block, n will be 7.

regards,
George

Thanks Mats,


I agree your undo and commit solutions.

1.

The point we discussed here is compiler or runtime during stack unwinding never helps to restore the state of function_local_object) just after manipulate_data (&function_local_object) is called. We have to do such things (like you mentioned undo and commit) by ourselves.

2.

Undo and commit may both expensive.

Originally Posted by matsp

There are several ways you can achieve this, but all involve storing some "undo-data". If it's hard/expensive to store the entire object [e.g. the object represents the current document of several megabytes in your word processor], then you can store "what changes are being made", and then undo those steps as appropriate in the catch phase.

An alternative process is to do prepare and commit - so you prepare a set of changes, and once you know that everything is OK (no exceptions) you "commit" your list of changes to the object - it's the same principle as the undo list, but the other way around.

Neither of these are trivial solutions, and "recovering to previously known good state" is not an easy problem to solve, ever.

--
Mats

regards,
George

Thanks Mats,


My question is answered. I am happy that from you I not only answered myself the original question, but also learning extra things. Cool!!

Originally Posted by matsp

Correct, the exception handling does not restore objects to the state before the try (or any other state), the object will be in whatever state it happens to be when the exception is thrown, and it's up to the application code to make sure that this state is consistent with whatever rules the application and the user expects it to follow.

Yes, any form of undo/commit or copying of objects will involve "extra work" - so it will have a cost applied to it. But if that's what you need, then you must do that. If it's not necessary, then it is of course wasted effort.

--
Mats

have a good day,
George