I dont know whether this method is practice.
Please correct me.

I missed that you did mention that compilation with /EHa is required – sorry, my bad.

There are two negative side effects with the use of /EHa. First, the overhead of the asynchronous unwind code affects performance and generates larger binaries. Second, compilation with /EHa causes catch(…) handlers to be entered for Win32 exceptions. Your post states that “This problem does not occur in Visual C++ 2005, where catch(…) never catches Win32 exceptions.”. This isn’t correct as the following code demonstrates:

#include

int main()
{
try
{
volatile int* pi = NULL;
volatile int i = *pi;
}
catch(…)
{
std::cerr << “Caught exception” << std::endl;
}
return 0;
}

Compile this with “cl /O2 /EHa /Zi /MD main.cpp /Femain.exe” and run main.exe and you’ll see that the access violation does cause the catch(…) handler to be invoked.

For all the reasons enumerated in your excellent post, this is disastrous for code quality and in my opinion sufficient reason to not compile with /EHa.

Unfortunately, I was mistaken in my previous comment regarding async-exception safe setjmp/longjmp. I have since discovered that neither the “setjmp.h” or “setjmpex.h” setjmp/longjmp implementations are async-exception safe since both attempt to unwind the stack. The Microsoft documentation is confused about this – see http://msdn.microsoft.com/en-us/library/yz2ez4as.aspx. This documentation currently contradicts itself with regard to whether or not C++ stack objects are destroyed when longjmp is called. In our environment (compiling with /EHsc), we have seen crashes with call stacks like this:

msvcr80!raise+0×187
msvcr80!abort+0x3d
msvcr80!terminate+0x4d
msvcr80!_inconsistency+0×22
msvcr80!__FrameUnwindToState+0x4b
msvcr80!__CxxLongjmpUnwind+0×14
msvcr80!longjmp+0×76

The fact that longjmp called a function named CxxLongjmpUnwind suggests that it does in fact destroy C++ stack objects while unwinding.

This has left me in a bind. We need to do something like what you are suggesting – return to a previous execution point when a Win32 exception occurs, but compiling with /EHa is too burdensome since it will cause uses of catch(…) to catch Win32 exceptions. I had turned to setjmp/longjmp hoping to solve the problem that way (I don’t care about C++ stack objects being destroyed when returning to the previous execution point). Unfortunately, I’m probably going to have to implement my own setjmp/longjmp routines to do this safely without performing C++ stack unwinding.

Ideally, Microsoft would provide versions of setjmp/longjmp that do not attempt to perform C++ stack unwinding – similar to how the Single UNIX Spec provides sigsetjmp/siglongjmp to handle asynchronous signals.

You must also compile with the /EHa compiler option to enable asynchronous exception handling. At runtime, you install your handler by calling the global function _set_se_translator().

The dire consequences you describe can indeed happen in code compiled with /EHs. But using /EHa pretty much solves all these problems. Following the approach I describe in the article should yield well-behaved and useful C++ exceptions. I’d like to know about any problems with this approach.

At the point that a Win32 exception occurs, the stack and objects on the stack may not be in a consistent state. Without the instructions added when compiling with /EHa, stack unwinding may result in destructors being called for partially constructed/destructed objects – which is a very bad thing. Additionally, partially constructed objects may not be unwound properly (or at all) leading to resource leaks.

Win32 exceptions and exception handlers have all the same challenges as signals and signal handlers have on POSIX platforms. I once read about someone advocating throwing C++ exceptions from signal handlers – which is a bad idea for exactly the same reasons as described above.

I recommend that catching of Win32 exceptions be limited to regions of code which do not require stack unwinding (ie, catch the exception in the stack frame that generated it and don’t place any C++ objects in the try/catch block). Or, use the async-exception safe longjmp/setjmp APIs (the ones in setjmp.h, NOT setjmpex.h). These longjmp/setjmp APIs will not call destructors for objects on the stack, but will ensure that the stack is unwound safely. Unfortunately, MS developers messed this up by not providing distinct interfaces to the async-exception safe setjmp/longjmp APIs (On POSIX systems, sigsetjmp and siglongjmp exist for this exact reason). You need to be very careful to ensure that setjmpex.h was not included prior to setjmp.h