Click here to Skip to main content
15,868,419 members
Articles / Programming Languages / C#

Stop Wrapping Exceptions in Exceptions: Use the .Data Collection on an Exception Instead

Rate me:
Please Sign up or sign in to vote.
4.82/5 (42 votes)
5 Feb 2010CPOL3 min read 55.5K   70   11
Presenting the little known .data property on an exception as a way to collect and transfer information about the circumstances surrounding an exception

Introduction 

Whether you are writing a WinForms application or a complex .NET web site, you will invariably be catching exceptions, logging them and reporting them somewhere. (In this article, I'm not going to explain how to log exceptions). Simply reporting the exception as-thrown rarely captures enough information to be able to diagnose what happened. A FileNotFoundException for instance isn't much use unless you know which file it was. 

One way to deal with this issue is to wrap an exception up in a more explicit exception that includes the extra information, e.g.  

C#
string filename ...
try
{
   //... do something with the file
} 
catch (FileNotFoundException ex)
{
   CustomException ex2 = new CustomException("Missing cache: " + filename", ex);  
   throw ex2;
} 

This approach works but it leads to a lot of custom exceptions that are just extra work to create and maintain.  Sometimes you'll want a custom exception because you are going to handle it in a different way in some outer scope, but often you cannot proceed and just want to log the error and redirect the user to an error page. In these cases, you can simplify things greatly using the .data property on an Exception. This is an IDictionary for a "collection of key/value pairs that provide additional user-defined information about the exception" [MSDN]. 

Using this approach, you can write:

C#
try
{
   ...
} 
catch (FileNotFoundException ex)
{
   ex.Data.Add("cache filename", filename);
   throw;
} 

Each surrounding scope can include a similar Try-Catch that adds more information to .Data so you get the full picture as to what might have caused the exception.

At a higher level in your Global.asax file where you catch all unhandled exceptions, you might want to also go add to .Data for all the interesting parameters on HttpContext like RawUrl, cookies, ...

C#
ex.Data.Add("RawUrl", 

request.RawUrl);
try
{
   foreach (string cookieName in request.Cookies)
   {
      try
      {
         HttpCookie cookie = request.Cookies[cookieName];
         string key = "Cookie " + cookie.Path + " " + cookieName;
         if (!ex.Data.Contains(key))
         {
             ex.Data.Add(key, cookie.Value.ToString());
         }
      }
      catch 
      {
         // deliberately nothing in here, should 
         // never happen, just being cautious
      }
   }
   // An extension method I use to spot bots - write your own ...
   if (request.IsABot())
   {
      ex.Data.Add("BOT", "************* BOT *****************");
   }
   ex.Data.Add("UserAgent", request.UserAgent);
   ex.Data.Add("Referrer", request.UrlReferrer);
   ex.Data.Add("User Host", request.UserHostName);
}
catch
{
   // deliberately nothing in here, should 
   // never happen, just being cautious
   // but we definitely don't want to cause 
   // an exception while handling one!
}

Exception Reporting Code

Now in your exception reporting code, you can write out the exception message and stack trace followed by a dump of all the key value pairs in .Data. I tend to use log4net on each server writing to a rolling log file and SQL server to capture the exception data centrally. For SQL, you'll probably want one table for the Exception itself and another table with a row for each key/value pair in .Data.

Points of Interest  

One cause of Exceptions on web servers is bots and client-side 'web accelerators'.  Both of these can hit pages with incorrect or outdated parameters that you simply didn't expect to receive. That's why I add a BOT warning on every exception as the exception itself may seem severe but in reality it's benign and no user has ever seen it. We found one antivirus product that actually takes each request you make and sends the URL to Japan where another server makes a second request back to check the page for viruses! It even pretends not to be a Bot in the UserAgent and of course, all your 'security- through-obscurity' URLs are now sitting on a server in Japan, but you know security through obscurity is no security at all, right?

Another browser add on called FunWebProducts would routinely corrupt Viewstate information so if you see that in your exceptions log, you know who to blame.

History

  • V1.1.1 - Made code snippets a bit more readable (JSOP)
  • V1.1 - Corrected 'throw ex' to 'throw' since you will want to preserve the call stack

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
United States United States
I have been writing code and managing teams of developers for more years than I care to remember.

Comments and Discussions

 
GeneralVery clever Pin
mattraffel28-Apr-09 1:10
mattraffel28-Apr-09 1:10 
I appreciate the time you took to show me about something I didn't know. Very useful.


Matt

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.