Exceptional wisdom

dcook — Thu, 29 Mar 2007 09:09:00 GMT

In Visual C++ 7.1 and earlier, "catch(...)" would catch all exceptions, both C++ and SEH. The behavior has changed with Visual C++ 8.0. This has caused some confusion.

The details get a bit tricky, but the generally accepted wisdom among the C++ gurus that have advised me is:

try/catch is for C++ exceptions.

Corollary: Don't catch C++ exceptions with __except.

__try/__except is for Windows Structured Exception Handling (SEH) exceptions.

Corollary: Don't catch SEH exceptions with catch.
Corollary: Don't use _set_se_translator. Use __except, then throw your C++ exception from the __except block.
Corollary: Don't use /EHa. The only reason to use /EHa is to catch SEH exceptions with catch or via _set_se_translator, which you shouldn't be doing in the first place.

Don't use both C++ exception handling and SEH exception handling in the same function.

Creating an instance of an object that has a destructor implicitly generates a try/catch block, so don't create destructable objects in a function that uses __try/__except or might directly raise an SEH exception.

Don't catch anything you don't know how to handle.
You don't know how to handle Access Violations.

Corollary: Don't catch Access Violations. Ever.

It was always kind of weird (many would say horrible and bad) that the C++ catch would sometimes catch SEH exceptions. This was never dependable. Don't rely on this behavior.
It is a compiler implementation detail that __except can catch C++ exceptions. Don't rely on this behavior.
Visual C++ 8.0 changed the semantics of "catch(...)".

catch(...) no longer catches all SEH exceptions. This is a good thing (see rules 4 and 5).
If you were following the above rules, you didn't see any changes in your program's behavior.

Where are we going, and what's with the handbasket? : c++

Exceptional wisdom