Chris
Chris

Reputation: 3712

Using Exception.Data

How have you used the Exception.Data property in C# projects that you've worked on?

I'd like answers that suggest a pattern, rather than those that are very specific to your app.

Upvotes: 60

Views: 26554

Answers (5)

Chr.
Chr.

Reputation: 73

I just tried to use it and found out that it is not very useful for my purpose - so I am not using it.

The most important part of the stack trace is to be able to tell what happened. The method name and line number are great, but you often need to see value of relevant variables in the context of the exception. I thought that was the whole point of the Data. But - you have to see it for it to be useful.

In my case, I control the code around the caught exception but not the code that logs it. So, for me Data is useless if it is not being automatically printed out in the stack trace. I might as well log the values myself rather than add them to the Data. Or, somehow modify the message to add the values in it, so that it gets logged but without losing the original stack trace with line numbers and method names.

Upvotes: 0

Ian Mercer
Ian Mercer

Reputation: 39277

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.

Upvotes: 14

Chris Marisic
Chris Marisic

Reputation: 33098

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();

Upvotes: 25

Austin Salonen
Austin Salonen

Reputation: 50215

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.

Upvotes: 30

Peter Meyer
Peter Meyer

Reputation: 26051

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!

Upvotes: 18

Related Questions