Sometimes the mundane act of giving a concept or feature a good name goes a long way in simplifying it and making it easier to grapple with. Even if it is just a small time-saver. The Base Exception concept in .NET exception handling is a good example – one that we’ll return to shortly.

When handling exceptions in C#, sometimes you will find that the exception you see in your catch block holds a great deal more data than you might realize at first glance.

The most obvious is the Message property which might explain what happened (in prose), or perhaps the HResult property which might explain what happened (after reviewing documented return codes, or perhaps after a Google search on the returned value).

Further, different Exception types may also have additional specialized properties, such as the ParamName property on the ArgumentNullException class.

And then sometimes there is the motherlode of additional exception data: an inner exception. When the InnerException property is not null, it contains a copy of an entire additional exception, usually one more specific than the one you caught directly. And an InnerException property can contain its own InnerException property, creating an arbitrarily deeply nested chain of exceptions.

This can be invaluable information, but how do you dig out the most deeply nested one – since that’s most likely the exception that started causing trouble in the first place.

You basically have two choices.

Choice #1 – dig it out “by hand” using a loop:

catch (Exception ex)
{
   var baseEx = ex;
   while (baseEx.InnerException != null)
   {
      baseEx = baseEx.InnerException;
   …
   }
}

Or Choice #2 – and the better choice – is to realize that there is a name for this exception – in the .NET Framework it is known as the Base Exception – and simply ask for it by name. All Exception and Exception-derived classes have a GetBaseException method.

catch (Exception ex)
{
   var baseEx = ex.GetBaseException();
   …
}

I’ve found that in debugging Windows Azure Cloud applications, jumping directly to the Base Exception is often a productive first step in zooming in on the root cause of the issue at hand.

Hopefully this post gives you some insight into more efficient understanding of exceptions in your own applications – and a small helper in digging out the Base Exception.