Types of SEH Clauses

Types of SEH Clauses

Exception handling clauses are classified by the algorithm of the handler engagement. Four mutually exclusive EH clause types are available, and because of that the Flags entry must hold one of the following values:

• 0x0000  The handler must be engaged if the type of the exception object matches the type identified by the token specified in the ClassToken entry or any of its descendants. Theoretically, any object can be thrown as an exception, but it’s strongly recommended that all exception types be derived from the [mscorlib]System.Exception class. This is because throughout Microsoft .NET Framework classes the construct catch [mscorlib]System.Exception is used in the sense of “catch any exception”—it is an analog of catch( ) in C++. In other words, [mscorlib]System.Exception is presumed to be the ultimate base class for all exceptions. This type of EH clause is called a catch type.

• 0x0001  A dedicated block of the IL code, called filter, will process the exception and define whether the handler should be engaged. The offset of the filter block is specified in the FilterOffset entry. Since we cannot specify the filter block length—the EH clause structure contains no entry for it—a positioning limitation is associated with the filter block: the respective handler block must immediately follow the filter block, allowing the length of the filter block to be inferred from the offset of the handler. The filter block must end with the endfilter instruction, described in Chapter 10, “IL Instructions.” At the moment endfilter is invoked, the evaluation stack must hold a single int32 value, equal to 1 if the handler is to be engaged and equal to 0 otherwise. This EH clause type is called a filter type. Branching into or out of the filter block is illegal.

• 0x0002  The handler will be engaged whether or not an exception has occurred. The EH clause entry ClassToken/FilterOffset is ignored. This EH clause type is called a finally type. The finally handlers are not meant to process an exception but rather to perform any cleanup that might be needed when leaving the guarded block. The finally handlers must end with the endfinally instruction. If no exception has occurred within the guarded block, the finally handler is executed at the moment of leaving that block. If an exception has been thrown within the guarded block, the finally handler is executed after any preceding handler is executed or, if no preceding handler was engaged, before any following handler is executed. If no catch or filter handlers are engaged—that is, the exception is uncaught—the finally handler has no chance to be engaged either, because it does not catch exceptions by itself.

  Figure 11-1 illustrates this process. If an exception of type A is thrown within the guarded block, it is caught and processed by the first handler (catch A), and the finally handler is engaged when the first handler invokes the leave instruction. If an exception of type B is thrown, it is caught by the third handler (catch B), and the finally handler is executed before the third handler. If no exception is thrown within the guarded block, the finally handler is engaged when the guarded block invokes the leave instruction.

• 0x0004  The handler will be engaged if any exception occurs. This type of EH clause is called a fault type. A fault handler is similar to a finally handler in all aspects except one: the fault handler is not engaged if no exception has been thrown within the guarded block and everything is nice and quiet. The fault handler must also end with the endfinally instruction, which for this specific purpose has been given the synonym endfault.