What should I know about Structured Exceptions (SEH) in C++?

Question

What important points about Structured Exceptions should every C++ developer know?

Answer 1

They should know that they are not part of Standard C++ - they are Microsoft invention and can be used in languages other than C++.

Answer 2

They are the Win32 equivalent to Unix signals, and let you catch CPU exceptions such as access violation, illegal instruction, divide by zero.

With the right compiler options (/EHa for Visual C++), C++ exceptions use the same mechanism as stack unwinding works properly for both C++ (user) exceptions and SEH (OS) exceptions.

Unlike C++ exceptions, SEH are not typed but all share the same data structure which has an exception code (the cause) and additional information on what code faulted and what the CPU registers held at the time of the fault. See GetExceptionCode and GetExceptionInformation for more details on this.

Also, SEH has "first-chance" handling, which allows you to log or otherwise handle the exception before unwinding destroys all the local variables.

Answer 3

There is nothing about them them every C++ programmer really needs to know. They're specific to Windows, so programmers who don't work on Windows don't normally need to know anything about them unless they're porting code from Windows that uses them.

People who do program on Windows should probably know that their capabilities are almost entirely different from the capabilities of C++ exception handling. Where C++ exceptions are (should be) used only in truly unusual or unexpected circumstances, structured exceptions are often used to deal with situations that are quite common and expected.

They should probably also know that structure exception handling is obsolescent -- unless you need to work with older versions of Windows (i.e., prior to XP), you normally want to use Vectored Exception Handling instead (although vectored exception handling is pretty much a superset of SEH, so it's not like you'd ignore SEH, but that you should be aware of the capabilities of VEH that aren't provided by SEH).

Answer 4

A Crash Course on the Depths of Win32™ Structured Exception Handling

That article is the reference on getting up to speed with SEH. 13 years later, is still the best there is.

There is a dedicated topic on MSDN for SEH vs. C++ Exception Handling Differences.

Some things a C++ developer should know if SEH is being discussed:

Writing C/C++ SEH Exception Handlers:

__try 
{
   // guarded code
}
__except ( expression )
{
   // exception handler code
}

This is not C++ exception handling, is the MS specific extensions for hooking straight inot SEH. It works very differently from your run-of-the-mill C++ exceptions. You need a good understanding of SEH to use these.

Writing C/C++ SEH Termination Handlers:

__try {
   // guarded code
}
__finally ( expression ) {
   // termination code
}

Same as with the SEH handler, do not confuse this with C++ exception semantics. You need a good understanding of SEH.

_set_se_trasnlator: this is the function that translates SEH exceptions into C++ type exceptions when asynchronous exceptions are used /EHa.

And finally, a personal opinion: should a C++ developer know SEH? After your first rookie .ecxr you'll understand that when the push come to shove C++ exceptions are just an illusion provided for your convenience. The only thing going on is SEH.

Answer 5

Although this question is from 5 months ago, I recently had a problem which was caused indirectly by SEH, specifically because of one feature of SEH which I think every developer should be aware of:

When SEH is used destructors are not called, so if you have cleanup code in your destructor it will not be cleaned up.

Our problem was caused by a Critical Section that was wrapped by an object with Lock in the constructor and Unlock in the destructor.

We had a deadlock situation and couldn't figure out why, and after about a week of digging through the code and dumps and debugging we finally understood it was because there was an exception that was handled by COM and causing the Critical section to stay locked. We changed a compilation flag in VS in the project properties which tell it to run destructors even for SEH and that solved the problem.

So even though you may not use SEH in your code, you may be using a library that does (like COM) and that can cause unexpected behaviour.