Subterranean IL: Exception handling

Comments 0

Share to social media

Today, I’ll be starting a look at the Structured Exception Handling mechanism within the CLR. Exception handling is quite a complicated business, and, as a result, the rules governing exception handling clauses in IL are quite strict; you need to be careful when writing exception clauses in IL.

Exception handlers

Exception handlers are specified using a .try clause within a method definition.

As an example, a basic try/catch block would be specified like so:

There are four different types of handler that can be specified:

  1. catch <TypeToken>
    This is the standard exception catch clause; you specify the object type that you want to catch (for example, [mscorlib]System.ArgumentException). Any object can be thrown as an exception, although Microsoft recommend that only classes derived from System.Exception are thrown as exceptions.
  2. filter <FilterLabel>
    A filter block allows you to provide custom logic to determine if a handler block should be run. This functionality is exposed in VB, but not in C#.
  3. finally
    A finally block executes when the try block exits, regardless of whether an exception was thrown or not.
  4. fault
    This is similar to a finally block, but a fault block executes only if an exception was thrown. This is not exposed in VB or C#.

You can specify multiple catch or filter handling blocks in each .try, but fault and finally handlers must have their own .try clause. We’ll look into why this is in later posts.

Scoped exception handlers

The .try syntax is quite tricky to use; it requires multiple labels, and you’ve got to be careful to keep separate the different exception handling sections. However, starting from .NET 2, IL allows you to use scope blocks to specify exception handlers instead. Using this syntax, the example above can be written like so:

As you can see, this is much easier to write (and read!) than a stand-alone .try clause.

Next time, I’ll be looking at some of the restrictions imposed by SEH on control flow, and how the C# compiler generated exception handling clauses.

Load comments

About the author

Simon Cooper's contributions