-
January 24th, 2014, 06:25 PM
#1
SEH hanlder cause compiler warnings and errors
I use a SEH handler in my code, like this:
__try
{
.. Some codes ...
}
__except(
EXCEPTION_EXECUTE_HANDLER
)
{
TRACE(_T("Exception"));
}
but get the following compiler errors:
1>e:\test.cpp(3310): warning C4509: nonstandard extension used: 'CMyClass::Test' uses SEH and 'iterator' has destructor
1> e:\test.cpp(3290) : see declaration of 'iterator'
e:\test.cpp(3450): error C2712: Cannot use __try in functions that require object unwinding
How to fix this?
Thanks
-
January 25th, 2014, 06:03 AM
#2
Re: SEH hanlder cause compiler warnings and errors
Here are the causes and possible fixes, quoted from MSDN Library:
Compiler Warning C4509
nonstandard extension used: 'function' uses SEH and 'object' has destructor
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.
Compiler Error C2712
cannot use __try in functions that require object unwinding
When you use /EHsc, a function with structured exception handling cannot have objects that require unwinding (destruction).
Possible solutions:
• Move code that requires SEH to another function
• Rewrite functions that use SEH to avoid the use of local variables and parameters that have destructors. Do not use SEH in constructors or destructors
• Compile without /EHsc
Last edited by ovidiucucu; January 25th, 2014 at 06:07 AM.
-
January 27th, 2014, 07:50 AM
#3
Re: SEH hanlder cause compiler warnings and errors
or put another way...
C++ exception handling and SEH are two entirely different beasts that don't really like eachother.
If you need SEH, then minimize the scope of the code you need it for, put that code in a separate function, handle the case and if needed repackage into a C++ exception and throw that to Ensure unwinding.
In the SEH code:
- Don't allow C++ exceptions to unwind through it.
- Avoid RAII features (avoid C++/STL entirely if you can and stick to "c" type code, new/delete tends to be a bad idea in a SEH handler)
- don't allow a SEH exception to "pass through" the kernel. This won't work properly. If this happens in a Win32 app running on Win64 this WILL cause your app to crash (you can trap it, but you'll loose the inner exception information).
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|