views:

73

answers:

2

When I log errors, I typically include the stack trace. This is good, but often, it's difficult to tell where the error actually is.

Is it possible to set up a routine that collects, perhaps via reflection, the parameters, the local variables, etc... at the time the error has occurred?

A: 

If you can upgrade to VS2010, you can try using the IntelliTrace feature, which does exactly this.

John Saunders
Though you might need to take out a second mortgage to pay for the Ultimate edition license. :)
Dan Bryant
I meant once I deploy the app into production, not during development.
AngryHacker
First of all, you shouldn't be having these problems in production. Do better testing, and have them in Test first. Second, I'm not sure, but it's possible that some of this might be available in production. I'd be surprised if the data collectors actually need to be launched from visual studio.
John Saunders
+2  A: 

If you don't have VS2010, you can use PostSharp to weave in code to collect parameters as functions are called. It will slow down code, though, so it's only useful for debugging.

EDIT: (promoting this from a comment I just made)

If you want to use this in production, you can either limit the scope of the PostSharp weaving, so it only operates on certain classes/namespaces/assemblies (or even functions), or you can limit what you do when your advice is executed. One thing I tried, but didn't fully follow through on, was to have the advice methods simply record stack frame information in a ring buffer. When an exception occurs, your logger can grab the stack frame information from the ring buffer and generate a suitable log message. Otherwise, the frame information is just overwritten as the ring buffer fills up. You could even just use a stack instead of a ring buffer and have that stack grow and shrink, recording frame info, as the call stack grows and shrinks. Caveat: you won't be able to get frame information from framework code or 3rd party code that can't be modified by PostSharp.

siride
PostSharp is a good way to enable Trace logging for debug purposes, but this can definitely generate a _lot_ of noise if not used cautiously. I've seen apps in production that generate 100s of MB of log files every day. It's valuable data to have as long as you have the disk space, can tolerate the performance hit and have the appropriate tools in place to parse/filter the logs so that you can make sense of them.
Dan Bryant