life cycle of exception object

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

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?

Quote:

---

Originally Posted by 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

---

regards,
George

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

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

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?

Quote:

---

Originally Posted by 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

---

regards,
George

I wouldn't think so, but I don't know what you know and what you don't know.

--
Mats

Thanks Mats,


At least I improved my knowledge about this topic. I appreciate your patience and knowledge sharing. :-)

Quote:

---

Originally Posted by matsp

I wouldn't think so, but I don't know what you know and what you don't know.

--
Mats

---

regards,
George

Quote:

---

Originally Posted by George2

Seems confusing. My code shows a temporary object is needed. Seems you mentioned a case when temporary object is not needed -- which is not the same as I have mentioned. You mean compiler optimization to avoid creating a temporary object?

---

Your code shows that your compiler introduces a temporary in your particular example. Another compiler is not required to do that.

Quote:

---

Originally Posted by George2

What do you mean "the only way of detecting the existence of that temporary is by tracking constructor and destructor calls"?

---

It means what it says.

In your code, you only know that the temporary exists because you have modified the constructor of the object object class (and it reports when it is called). In effect, you are tracking constructor calls: getting a report during execution of a constructor.

You could also have put code into the destructor (or a function called by the destructor) to achieve the same thing.

There is no other alternative other than compiler specific hacks, use of debuggers, etc.

This means that (other than modifying constructors, destructors, or functions called by them) you have no way of detecting if a temporary exists or not.

Quote:

---

Originally Posted by George2

You mean if compiler optimize the code and does not generate temporary, and let the exception object in the catch block the same as the one in try block?

---

The exception handler, in principle, receives a copy of the object thrown. But, if you can't distinguish between the original and a copy of it, there is nothing that forces the compiler to create copies of the original exception while unwinding the call stack. So there is nothing stopping the "copy" from actually being the original.

Quote:

---

Originally Posted by George2

If yes, I still do not know even in this way, why compiler needs to prolong the life cycle of the exception object instance in the try block?

---

Performance optimisation. Creating and destroying objects tends to be expensive (consumption of memory while objects exist, CPU cycles required to create and destroy them, etc.

If executable A (executable file, in which your compiler allows temporaries) and executable B (compiler eliminates temporaries) produce the same outputs, and we assume "faster and less memory usage is better", then executable B is usually more optimal than executable A.

If you cannot detect if a temporary is created (other than by modifying constructors and destructors) and the compiler can generate an executable that runs faster (but otherwise correctly), then the compiler need not create the temporary object.

Thanks grumpy,


Great!!

Previously, I am thinking when re-throw the exception (suppose the same one, and no exception translation), whether compiler wil make a copy or not. And I make the false assumption before that compiler will always re-throw the original exception when we re-throw it in catch block. Now I understand compiler may make a copy and re-throw the copied one. Right?

Quote:

---

Originally Posted by grumpy

If executable A (executable file, in which your compiler allows temporaries) and executable B (compiler eliminates temporaries) produce the same outputs, and we assume "faster and less memory usage is better", then executable B is usually more optimal than executable A.

If you cannot detect if a temporary is created (other than by modifying constructors and destructors) and the compiler can generate an executable that runs faster (but otherwise correctly), then the compiler need not create the temporary object.

---

regards,
George

No, as specified in 15.1/4. As I said before, that was the one factual error in grumpy's post. An argument-less throw re-throws exactly the same object.

Quote:

---

Originally Posted by CornedBee

No, as specified in 15.1/4. As I said before, that was the one factual error in grumpy's post. An argument-less throw re-throws exactly the same object.

---

Thanks for the correction :)

Thanks CornedBee,


What is a "argument-less throw"? Show some pseudo code please?

Quote:

---

Originally Posted by CornedBee

No, as specified in 15.1/4. As I said before, that was the one factual error in grumpy's post. An argument-less throw re-throws exactly the same object.

---

regards,
George

Quote:

---

Originally Posted by George2

Thanks CornedBee,


What is a "argument-less throw"? Show some pseudo code please?

---

Code:

---

throw;

---

Quote:

---

What is a "argument-less throw"?

---

Basically:

Code:

---

throw;

---

Thanks laserlight,


So the conclusion is,

1. for the argument-less for of throw, which will throw the same exception object

2. all the other forms of throw may make a copy of original exception object or may not, depends on implementation?

Quote:

---

Originally Posted by laserlight

Basically:

Code:

---

throw;

---

---

regards,
George