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.
Thanks!
+9
A:
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!
Peter Meyer
2008-09-28 02:26:45
The only problem with this approach is that Data property is defined as virtual, which means you shouldn't use it in Exception's constructors (reported by FxCop). Which is kind of a problem if you want to have a constructor setting your custom properties linked to the Data dictionary.
Igor Brejc
2010-01-20 15:43:10
A valid point; however, it can be mitigated in two ways:1. Don't provide a constructor to set these properties (and in turn make the virtual call.) Rather, only provide get/set property accessors and use object initializer syntax.2. Mark your exception class as sealed. While "sealed" generally rubs me the wrong way, in many cases where a custom exception class is concerned, it may be perfectly legitimate.
Peter Meyer
2010-01-21 17:50:49
+6
A:
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.
Austin Salonen
2008-09-28 03:07:17
+1
A:
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.
Hightechrider
2010-03-08 07:24:40