The Visual C++ Exception Model
by Howard Jeng

Contents   Page 1   Page 2   Page 3   Page 4   Printable version   Discuss this article

When programming in C++ with Microsoft Visual C++, your program has two exceptions models: the normal C++ exception model and the Structure Exception Handling (SEH) exception model.¹⁾ MSVC's C++ exception system is, in fact, implemented with SEH's functionality. This implementation leads to some interesting behaviors.

This article discusses some of the consequences of the MSVC exception system from the standpoint of a C++ programmer. It assumes familiarity with C++ exceptions, including exception aware programming techniques like RAII, and basic Windows programming.²⁾ It does not assume any background with SEH. The behavior described covers MSVC .NET 2002, 2003, 2005 and 2008.

An Introduction to Structured Exception Handling

Structured Exception Handling is a mechanism built into the operating system that provides facilities to detect and deal with exceptional circumstances, much as C++ exceptions do for C++ programs. SEH exceptions come in two varieties: hardware exceptions and software exceptions. Hardware exceptions are exceptions raised by the CPU such as access violations and divide by zero. Software exceptions are exceptions raised explicitly by programs or, on occasion, the operating system itself. For the purposes of this article, there isn't much difference between the two.

When an exception is raised, two pieces of information are captured: one is the state of the processor at the time of the exception, which is stored in a CONTEXT structure³⁾. The other is information about the exception, which is stored in an EXCEPTION_RECORD. The two parts of this structure we'll be concerned about are the ExceptionCode member and the ExceptionInformation array, which contain a numeric value for the exception type and additional information respectively. For example, when an access violation is detected, a hardware exception is raised with the code 0xC0000005. If ExceptionInformation[0] is zero the access violation was caused by a read and if ExceptionInformation[0] is non-zero the access violation was triggered by a write, and ExceptionInformation[1] is the address that was read from or written to. Not all exceptions generate additional information; in fact, the majority don't. To raise a software exception, code can call the RaiseException() function, which takes an exception code and other exception information, which will then be packaged into an EXCEPTION_RECORD.

Windows exception codes follow the following format: Bits 31 and 30 represent the severity code. It should be 00 for success, 01 for informational, 10 for warning and 11 for an error. Bit 29 is set for user exception codes. Bit 28 is reserved and should not be set. Bits 27 to 16 represent a facility code. For example, Windows Update is assigned the facility code of 36, while 0 represents no particular facility. The bottom 16 bits then represent the actual error code. This is why exceptions like access violations start with 0xC: these codes represent non-user error exceptions. In theory, most user exception codes should start with 0xE to represent user defined error exceptions⁴⁾.

Actually dealing with SEH exceptions in MSVC takes two primary forms: frame based exception handling (__try/__except blocks) and termination handling (__try/__finally blocks).

Frame Based Exception Handling

Frame based exception handling is roughly analogous to C++'s try/catch blocks. Instead of try/catch, the blocks look like:

__try {
  // code to attempt to execute
} __except (filter_expression) {
  // handler code
}

Unlike C++ catch block, where the catch contains types, the filter expression is more like the contents of the parenthesis after an if⁵⁾: it can be almost anything that eventually evaluates to a value. In particular, the filter expression must evaluate to one of three values: EXCEPTION_EXECUTE_HANDLER, EXCEPTION_CONTINUE_SEARCH or EXCEPTION_CONTINUE_EXECUTION. If the expression evaluates to EXCEPTION_EXECUTE_HANDLER, the code in the handler block is executed, much like when the type matches the catch for a C++ exception. If the expression evaluates to EXCEPTION_CONTINUE_SEARCH it looks for another __except block that might handle the exception, like when a C++ catch block doesn't contain a matching type ⁶⁾. EXCEPTION_CONTINUE_EXECUTION has no analogy in C++ exception handling: it causes program execution to resume from the point where the exception was raised ⁷⁾.

Unlike C++ catch blocks, you can't chain __except blocks. That is to say this code is illegal:

  __try {
    // stuff
  } __except (filter expression 1) {
    // handler 1
  } __except (filter expression 2) {
    // handler 2

  }

  __try {
    __try {
      // stuff
    } __except (filter expression 1) {
      // handler 1
    }
  } __except (filter expression 2) {
    // handler 2

  }

So what does a typical filter expression look like? If there was such a thing as a typical filter expression, it would probably look something like this:

  EXCEPTION_POINTERS * eps = 0;
  __try {
    // stuff

  } __except (eps = GetExceptionInformation(), EXCEPTION_EXECUTE_HANDLER) {
    // handler
  }

DWORD filter(EXCEPTION_POINTERS * eps) {
  if (eps->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
    return EXCEPTION_EXECUTE_HANDLER;
  return EXCEPTION_CONTINUE_SEARCH;
}
 
  EXCEPTION_POINTERS * eps = 0;
  __try {
  } __except (eps = GetExceptionInformation(), filter(eps)) {
  }

  EXCEPTION_POINTERS * eps = 0;
  __try {
  } __except (eps = GetExceptionInformation(), 
              ((GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) 
                  ? EXCEPTION_EXECUTE_HANDLER 
                  : EXCEPTION_CONTINUE_SEARCH)) {
  }

Termination Handling

Termination handling is much simpler than frame based exception handling. Instead of __try/__except, we have __try/__finally. The __try block is executed, and barring the thread or process ending, the code in the __finally block is executed unconditionally when the __try block is exited, whether the function returns, an exception is thrown, if there's a goto out of the block or the last statement in the __try block finishes executing.

  __try {
    // try to execute this code
  } __finally {
    // execute this code afterwards (unless the thread or process ends)
  }

  __try {
    __try {
      // try to execute this code
    } __finally {
      // execute this code afterwards (unless the thread or process ends)
    }
  } __except (filter_expression) {
    // exception handler
  }

Page 2