Using Exception.Data

I have used it when I knew the exception I was creating was going to need to be serialized. Using Reflector one day, I found that Excepion.Data gets stuck into and pulled from serialization streams.

So, basically, if I have properties on a custom exception class that are already serializable types, I implement them on the derived class and use the underlying data object as their storage mechanism rather than creating private fields to hold the data. If properties of my custom exception object require more advanced serialization, I generally implement them using backing private fields and handle their serialization in the derived class.

Bottom line, Exception.Data gives you serialization for free just by sticking your properties into it -- but just remember those items need to be serializable!

The exception logger I use has been tweaked to write out all the items in the Data collection. Then for every exception we encounter that we cannot diagnose from the exception stack, we add in all the data in that function's scope, send out a new build, and wait for it to reoccur.

I guess we're optimists in that we don't put it in every function, but we are pessimists in that we don't take it out once we fix the issue.

Since none of the answers include any code. Something that might useful as an addition to this question is how to actually look at the .Data dictionary. Since it is not a generic dictionary and only returns IDictionary

foreach(var kvp in exception.Data) the type of kvp will actually be object unhelpfully. However from the MSDN there's an easy way to iterate this dictionary:

foreach (DictionaryEntry de in e.Data)
    Console.WriteLine("    Key: {0,-20}      Value: {1}", 
                             "'" + de.Key.ToString() + "'", de.Value);

I don't really know what the format argument , -20 would mean, maybe Take(20)? Digressing... this code can be very helpful in a common error logger to unwind this data. A more complete usage would be similar to:

var messageBuilder = new StringBuilder();

do
{                
    foreach (DictionaryEntry kvp in exception.Data)
        messageBuilder.AppendFormat("{0} : {1}\n", kvp.Key, kvp.Value);

    messageBuilder.AppendLine(exception.Message);


} while ((exception = exception.InnerException) != null);

return messageBuilder.ToString();

I've used it to capture information about the state at the time of the Exception from the enclosing scope as the Exception travels up the stack. Items like the filename that caused the Exception, or the value of some ID that will help track down the problem.

At the top most level in a web application I also tend to add much of the Request information like the RawUrl, the cookies, the Referrer, ...

For more details here's my blog on the topic:

Rather than waiting for problems to happen I add this code in wherever an Exception can occur that's related to something external, e.g. a file name, or an URL that was being accessed, ... In other words, any data that will help repro the problem.