Can someone explain the difference between a C++ exception and a structured exception in MFC?
A C++ exception is a feature of the programming language C++. A structured exception is a different concept of the Windows operating system. These two use similar syntax, but are technically different. Windows structured exceptions are not only usable with C++ but also e.g. with C.
Sometimes a solution to unify the handling of both: In a Windows application you can provide a handler function, which catches all structured exceptions and throws a C++ exception (defined by you).
Both provide mechanisms for stack unwinding when errors occur.
Structured exceptions are provided by Windows, with support from the kernel. They are raised by Windows if you do things like access an invalid memory location. They also are used to support features like automatic stack growth. They're used fairly rarely by themselves, but language exceptions in C++, .NET, and similar languages are often built on top of them. You use special keywords like __try
and __catch
to deal with these exceptions. However, dealing with them is comparatively difficult and error-prone, because you can break features like automatic stack expansion, as well as potentially breaking C++ language exceptions.
C++ exceptions are specified by the C++ language. The data types that is thrown and caught are C++ objects (including the possibility of primitive types). The compiler and runtime implements these on top of the underlying structured exception mechanism. This is what you get if you use the try
, catch
and throw
keywords of the C++ language.
SEH exceptions have more features than C++ exceptions, like supporting resumption, and so-called "vectored" handlers (which receive notifications of exceptions, but don't necessarily prevent stack unwinding), but unless you specifically know you want to use them, I'd avoid them. Probably the most common use of them is to write a crash dump using MiniDumpWriteDump if your program does something illegal or undefined.
You actually have three mechanisms:
- C++ exceptions, implemented by the compiler (
try
/catch
) - Structured Exception Handling (SEH), provided by Windows (
__try
/__catch
) - MFC exception macros (
TRY
,CATCH
- built on top of SEH / C++ exceptions - see also TheUndeadFish's comment)
C++ exceptions usually guarantee automatic cleanup during stack unwinding (i.e. destructors of local objects run), the other mechanisms don't.
C++ exceptions only occur when they are explicitely thrown. Structured Exceptions may occur for any operation.
MFC did introduce the exception macros to support exceptions even if compilers didn't implement them.
C++ exceptions will work cross platform. Unfortunately SEH will severly restrict portability (except may be across different Windows versions).
Also SEH seems to capture lots of native Windows exceptions (like Access Violation, An Invalid handle was specified) etc.
It is a heavy implementation detail, but on Windows a C++ exception is also a SEH exception. The exception code is 0xE04D5343 (last three bytes = 'MSC'). And all of the regular SEH support is used to unwind the stack, get automatic cleanup code to run and to filter the exception so the proper catch clause is selected. Getting the thrown exception object in the filter expression is plumbing that's added by the CRT beyond what SEH provides. SEH also supports a __finally clause but that doesn't get used in standard C++.
A further implementation detail is the /EH compiler setting. The default (/EHsc) allows the compiler to optimize the code that's generated and suppress the exception filters that are needed to run automatic cleanup. If it can see that none of the emitted C++ code can throw an exception. This is above all a space optimization, a small time optimization for x86 code but not for x64 code. To get automatic cleanup for SEH exceptions you have to compile with /EHa so that this optimization is suppressed.
A good strategy to marry C++ exceptions with SEH is to use _set_se_translator() so you can translate an SEH exception to a C++ exception. Albeit that it isn't often wise to catch SEH exceptions, they are almost always nasty.