life cycle of exception object

[George2]

Hello everyone,


1.

Suppose I have code like this. According to the standard, the storage of exception object is undefined (could be either on stack or on heap?).

2.

I am wondering what is the life cycle of the exception object which reference variable e binded to? For example, could we bind a global reference to the exception object referred by e? Or doing something on the exception object beyond the bracket?

3.

The life cycle of variable e itself should not beyond the bracket, right?

catch (exception& e)
{
    // ...
}

thanks in advance,
George

[grumpy]

1) The storage of the exception object can be anywhere. Technically, doing "throw x;" where x is some object or value, then x ceases to exist when control passes out of the scope in which it was created. For example;

void f()
{
      {
           SomeType x;
           throw x;
      }
      //   x does not exist here
}

While x ceases to exist as soon as control is returned to an enclosing scope, a temporary copy of x exists until the exception is caught (or the program terminates due to an uncaught exception) -- and will be copied repeatedly as control passes to enclosing scopes. Then compiler implementation details kick in, as the standard explicitly allows (as opposed to "requires") the compiler to avoid creating a temporary if the only way of detecting that temporary is by tracking constructor and destructor calls.

2) and 3) The reference e exists until control leaves the scope of the catch block, as does the object e refers to. If the catch block rethrows the exception then, logically, a copy of the exception object will be created, and copied during stack unwinding. Practically, again, the compiler is allowed to be smarter than that, so it can avoid creating copies.

[George2]

Thanks grumpy,


Suppose in catch block we pass the address of the exception object to a global pointer variable or make a global reference variable binded to the exception object (let me know if I have not made myself understood). And after catch block or even after function returns, is it safe to access the global reference variable or the global pointer variable?

1) The storage of the exception object can be anywhere. Technically, doing "throw x;" where x is some object or value, then x ceases to exist when control passes out of the scope in which it was created. For example;

void f()
{
      {
           SomeType x;
           throw x;
      }
      //   x does not exist here
}

While x ceases to exist as soon as control is returned to an enclosing scope, a temporary copy of x exists until the exception is caught (or the program terminates due to an uncaught exception) -- and will be copied repeatedly as control passes to enclosing scopes. Then compiler implementation details kick in, as the standard explicitly allows (as opposed to "requires") the compiler to avoid creating a temporary if the only way of detecting that temporary is by tracking constructor and destructor calls.

2) and 3) The reference e exists until control leaves the scope of the catch block, as does the object e refers to. If the catch block rethrows the exception then, logically, a copy of the exception object will be created, and copied during stack unwinding. Practically, again, the compiler is allowed to be smarter than that, so it can avoid creating copies.

regards,
George

[matsp]

That would equivalent of taking a reference/address of a local variable in any other context, so no, this is not valid and leads to undefined behaviour.

--
Mats

[George2]

Thanks Mats,


I have written some code which verified that the caught object instance is not the original one we thrown. Looks like we only get a temporary exception object in catch block?

Here is my code. You can see two object instance is created.

#include <iostream>

using namespace std;

class Foo {
public:
	Foo(int input)
	{
		this->a = input;
		cout << this << endl;
	}

	Foo (const Foo& input)
	{
		this->a = input.a;
		cout << this << endl;
	}
	int a;
};

void foo()
{
	try {
		Foo* f = new Foo (100);
		throw *f;
	} catch (const Foo& e)
	{
		cout << e.a << endl;
	}
}

int main()
{
	foo();
}

That would equivalent of taking a reference/address of a local variable in any other context, so no, this is not valid and leads to undefined behaviour.

--
Mats

regards,
George

[matsp]

Yes, like Grumpy said, it's a temporary copy of the original object - the original object may even be destroyed by the time the catch is entered.

--
Mats

[CornedBee]

Your conclusions are wholly unnecessary.

1) They might be the same.
2) No, it might be merged with the exception object.
3) Of course not.


One addition to what grumpy said: a re-throw does not create a new exception object.

[George2]

Hi CornedBee,


Can you show me some pseudo code for (1) and (2) please?

Your conclusions are wholly unnecessary.

1) They might be the same.
2) No, it might be merged with the exception object.
3) Of course not.


One addition to what grumpy said: a re-throw does not create a new exception object.

regards,
George

[CornedBee]

Can you show me some pseudo code for (1) and (2) please?

No, it's a compiler optimization.

[George2]

Hi CornedBee,


I can understand the exception object in try and in catch may share the same object instance for compiler optimization purpose.

But what do you mean (2) -- "No, it might be merged with the exception object.". What do you mean merged?

No, it's a compiler optimization.

regards,
George

[matsp]

It means that if the compiler can clearly see that there is no need to copy the object - such as the throw and the object are within the same scope as the catch, then there is no need to copy the object, and the compiler doesn't do that. Just like the compiler can "omit" reading the same data twice if it knows that it hasn't changed. [Unless you tell it that the data is volatile].

--
Mats

[George2]

Thanks Mats,


I think the conclusion of this thread is quite flexible. :-)

1. The objct instance in try block may be the same as the one in try block, may be not. Dependent on compiler's optimization;

2. Safe to use the object instance in the catch block. But not safe to use it outside catch block.

Does I missed anything important as our conclusion?

It means that if the compiler can clearly see that there is no need to copy the object - such as the throw and the object are within the same scope as the catch, then there is no need to copy the object, and the compiler doesn't do that. Just like the compiler can "omit" reading the same data twice if it knows that it hasn't changed. [Unless you tell it that the data is volatile].

--
Mats

regards,
George

[CornedBee]

2) Er, what? It's definitely safe to use the exception object in the catch block.

[matsp]

I'm with CornedBee on this. However, the result of using a pointer, pointing to the exception object within the catch block, after leaving the catch block is DEFINITELY not OK.

--
Mats

[George2]

Thanks Mats,


I agree with you and CornedBee. It is my typo before.

About my conclusion in post #17, do you think I missed anything important?

I'm with CornedBee on this. However, the result of using a pointer, pointing to the exception object within the catch block, after leaving the catch block is DEFINITELY not OK.

--
Mats

regards,
George