compile error about destructor
-
Hello everyone, When change from __try to try, and __except(GetExceptionCode()) to catch(...), compile can pass. Compile error and code are, Compiling... main.cpp d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(30) : warning C4509: nonstandard extension used: 'main' uses SEH and 'foo1' has destructor d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(28) : see declaration of 'foo1' d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(35) : error C2712: Cannot use __try in functions that require object unwinding
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; __try{ Foo foo1; (*address) = 1024; } __except (GetExceptionCode()) { cout << "access violation caught" << endl; } return 0; }regards, George
-
Hello everyone, When change from __try to try, and __except(GetExceptionCode()) to catch(...), compile can pass. Compile error and code are, Compiling... main.cpp d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(30) : warning C4509: nonstandard extension used: 'main' uses SEH and 'foo1' has destructor d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(28) : see declaration of 'foo1' d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(35) : error C2712: Cannot use __try in functions that require object unwinding
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; __try{ Foo foo1; (*address) = 1024; } __except (GetExceptionCode()) { cout << "access violation caught" << endl; } return 0; }regards, George
-
Hello everyone, When change from __try to try, and __except(GetExceptionCode()) to catch(...), compile can pass. Compile error and code are, Compiling... main.cpp d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(30) : warning C4509: nonstandard extension used: 'main' uses SEH and 'foo1' has destructor d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(28) : see declaration of 'foo1' d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(35) : error C2712: Cannot use __try in functions that require object unwinding
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; __try{ Foo foo1; (*address) = 1024; } __except (GetExceptionCode()) { cout << "access violation caught" << endl; } return 0; }regards, George
Is it as simple as moving
Foo foo1outside of the try catch block? Iain. -
Is it as simple as moving
Foo foo1outside of the try catch block? Iain.Moving out Foo foo1 will result in the same compile error, my purpose of this post is to find the root cause of compiler error, i.e. at which point I violate the C++ standard. Any ideas, Iain? regards, George
-
Cannot use __try in functions that require object unwinding
: the above error means the usage of __try/__except is forbidden in the function which has objects which (the object) will be destroyed upon the function return.
Come online at:- jubinc@skype
Thanks Don Box, 1. Why using try/catch is ok? It is still structured exception. 2. Why the usage of __try/__except is forbidden in the function which has objects which (the object) will be destroyed upon the function return? I think the more accurate term to replace return is stack unwinding. :-) regards, George
-
Hello everyone, When change from __try to try, and __except(GetExceptionCode()) to catch(...), compile can pass. Compile error and code are, Compiling... main.cpp d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(30) : warning C4509: nonstandard extension used: 'main' uses SEH and 'foo1' has destructor d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(28) : see declaration of 'foo1' d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(35) : error C2712: Cannot use __try in functions that require object unwinding
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; __try{ Foo foo1; (*address) = 1024; } __except (GetExceptionCode()) { cout << "access violation caught" << endl; } return 0; }regards, George
Which means that the Standard C++ Exception model is more convenient!
Maxwell Chen
-
Moving out Foo foo1 will result in the same compile error, my purpose of this post is to find the root cause of compiler error, i.e. at which point I violate the C++ standard. Any ideas, Iain? regards, George
Sorry, I'm not much of an expert on exceptions etc. A weak point in my armoury. I'm old school, and check return values, instead of putting up a blast shield for when things blow up. I probably *should* do both... Iain.
-
Hello everyone, When change from __try to try, and __except(GetExceptionCode()) to catch(...), compile can pass. Compile error and code are, Compiling... main.cpp d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(30) : warning C4509: nonstandard extension used: 'main' uses SEH and 'foo1' has destructor d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(28) : see declaration of 'foo1' d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(35) : error C2712: Cannot use __try in functions that require object unwinding
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; __try{ Foo foo1; (*address) = 1024; } __except (GetExceptionCode()) { cout << "access violation caught" << endl; } return 0; }regards, George
MSDN said that:
You should not use structured exception handling in functions that use objects with destructors. If an exception occurs, the destructor cannot be called. Use C++ exception handling instead.I have never used SEH, c++'s exception handling is more powerful, I think :)A Chinese VC++ programmer
-
Which means that the Standard C++ Exception model is more convenient!
Maxwell Chen
I agree Maxwell! But could we come back to the original question please? Suppose we have to maintain some code using structured exception. :-) Why __try/__except does not work but try/catch work with structured exception? regards, George
-
Sorry, I'm not much of an expert on exceptions etc. A weak point in my armoury. I'm old school, and check return values, instead of putting up a blast shield for when things blow up. I probably *should* do both... Iain.
Thanks all the same, Iain! It is welcome if you could share some points in the future. :-) regards, George
-
MSDN said that:
You should not use structured exception handling in functions that use objects with destructors. If an exception occurs, the destructor cannot be called. Use C++ exception handling instead.I have never used SEH, c++'s exception handling is more powerful, I think :)A Chinese VC++ programmer
No zengkun100, The destructor could be invoked even if it is structured exception, if you change my code from __try to try, and change __except to catch. Here is the output, constructing Foo destructing Foo access violation caught You can see if we change the keyword, structured exception is caught and destructor is called before handler. Not as you quoted -- "If an exception occurs, the destructor cannot be called.". regards, George
-
Hello everyone, When change from __try to try, and __except(GetExceptionCode()) to catch(...), compile can pass. Compile error and code are, Compiling... main.cpp d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(30) : warning C4509: nonstandard extension used: 'main' uses SEH and 'foo1' has destructor d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(28) : see declaration of 'foo1' d:\visual studio 2008\projects\test_exception1\test_exception1\main.cpp(35) : error C2712: Cannot use __try in functions that require object unwinding
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; __try{ Foo foo1; (*address) = 1024; } __except (GetExceptionCode()) { cout << "access violation caught" << endl; } return 0; }regards, George
Try compiling without the /EHsc switch. As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors. Basically, use C++ exception handling where it is possible, and fallback to SEH only when there are no other ways. See here.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
Try compiling without the /EHsc switch. As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors. Basically, use C++ exception handling where it is possible, and fallback to SEH only when there are no other ways. See here.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
Hi DavidCrow, I compile with /EHa in my question and experiment. If you have Visual Studio, you can have a try. :-) 1. If you remove destructor, it is fine; 2. If you change to try/catch, it is fine. I do not know why. regards, George
-
Hi DavidCrow, I compile with /EHa in my question and experiment. If you have Visual Studio, you can have a try. :-) 1. If you remove destructor, it is fine; 2. If you change to try/catch, it is fine. I do not know why. regards, George
George_George wrote:
2. If you change to try/catch, it is fine.
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
George_George wrote:
I do not know why.
Now you do.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
George_George wrote:
2. If you change to try/catch, it is fine.
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
George_George wrote:
I do not know why.
Now you do.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
Hi DavidCrow, But even if in my sample, we use try/catch, we are still dealing with structured exception -- access violation, and access violation is not a C++ exception. :-) So, when change to try/catch, I do not agree with you we are in C++ exception category. Any comments?
DavidCrow wrote:
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
regards, George
-
No zengkun100, The destructor could be invoked even if it is structured exception, if you change my code from __try to try, and change __except to catch. Here is the output, constructing Foo destructing Foo access violation caught You can see if we change the keyword, structured exception is caught and destructor is called before handler. Not as you quoted -- "If an exception occurs, the destructor cannot be called.". regards, George
George_George, the answer is very clear now. Different keyword, different exception handling method. Use C++ exception handling whenever possible :)
A Chinese VC++ programmer
-
George_George, the answer is very clear now. Different keyword, different exception handling method. Use C++ exception handling whenever possible :)
A Chinese VC++ programmer
Any rule in C++ mentioned we can not use object with destructor in __try block with /EHa compile option? I can not find. So, I do not agree. :-) regards, George
-
Hi DavidCrow, But even if in my sample, we use try/catch, we are still dealing with structured exception -- access violation, and access violation is not a C++ exception. :-) So, when change to try/catch, I do not agree with you we are in C++ exception category. Any comments?
DavidCrow wrote:
As opposed to SEH, C++ exception handling model supports "stack unwinding". It is aware of automatic objects, and it calls their destructors.
regards, George
George_George wrote:
...we use try/catch, we are still dealing with structured exception...
Not according to everything that I've read on the subject. Microsoft's
__try/__catchis SEH. Perhaps you should read this."Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
Moving out Foo foo1 will result in the same compile error, my purpose of this post is to find the root cause of compiler error, i.e. at which point I violate the C++ standard. Any ideas, Iain? regards, George
George_George wrote:
at which point I violate the C++ standard
At the point of using MS-specific SEH.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency" -
George_George wrote:
...we use try/catch, we are still dealing with structured exception...
Not according to everything that I've read on the subject. Microsoft's
__try/__catchis SEH. Perhaps you should read this."Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
Yes, DavidCrow. What I do not agree with you is you mentioned when there is structured exception, during stack unwinding, the local object's destructor is not called. Through my experiment, it is not true. You can try the following code and see if structured exception occurs, like access violation, during stack unwinding, destructor is also called. So the question can be asked in two ways, 1. Why __try/__except does not work with structured exception with destructor; 2. Why try/catch work with structured exception with destructor. Now we are talking about (2).
#include #include #include using namespace std; class Foo { public: Foo() { cout << "constructing Foo" << endl; } virtual ~Foo() { cout << "destrucing Foo" << endl; } }; int main() { int* address = NULL; try{ Foo foo1; (*address) = 1024; } catch (...) { cout << "access violation caught" << endl; } return 0; }
regards, George