best practices for generating debugging logs and grabbing exception info

  • Thread starter Thread starter Darren Mar-Elia \(MVP\)
  • Start date Start date
D

Darren Mar-Elia \(MVP\)

So, I have my little .Net 2.0 C# utilities out in the wild and occasionally
they have bugs(!). Often the bugs are easy to troubleshoot remotely but
occasionally I would like to write detailed trace info to a simple text file
that I could use to further track down the bugs. Additionally, somewhat
related, it would be useful to be able to get the line number where an
exception was thrown, which is slightly different than a debug log, but
useful nonetheless. For the first part of this--the debug log--what is the
best method to do this? Any artices or samples that anyone can point me to?
Secondly, how can I pass the line number of the code into an exception that
would help me track down where the exception was thrown.

Thanks!

Darren

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
Group Policy Management solutions at http://www.sdmsoftware.com
 
Darren said:
So, I have my little .Net 2.0 C# utilities out in the wild and occasionally
they have bugs(!). Often the bugs are easy to troubleshoot remotely but
occasionally I would like to write detailed trace info to a simple text file
that I could use to further track down the bugs. Additionally, somewhat
related, it would be useful to be able to get the line number where an
exception was thrown, which is slightly different than a debug log, but
useful nonetheless. For the first part of this--the debug log--what is the
best method to do this? Any artices or samples that anyone can point me to?
Secondly, how can I pass the line number of the code into an exception that
would help me track down where the exception was thrown.
Click to expand...

For debug logging you could take a look at log4net.

Line numbers does not necesarrily make sense for
optimized code.

Arne
 
Thanks. Forgive my ignorance about your comment re: optimized code? What
would be the best way to determine which line of code threw an exception or
is your point that its not as straightforward as that?

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
Group Policy Management solutions at http://www.sdmsoftware.com
 
Darren said:
Thanks. Forgive my ignorance about your comment re: optimized code? What
would be the best way to determine which line of code threw an exception or
is your point that its not as straightforward as that?
Click to expand...

If you build with /debug+ then you can get a line number from
the stacktrace.

But if you also use /optimize+ then the line number may be
somewhat misleading but probably still somewhat usefull.

Arne
 
One other issue to keep in mind is that when writing error handling
and logging code it's important to provide as much information as
possible. It's all too common to have an error handler like this

try {
.... error ...
} catch(Exception ex) {
_log.Error("An error occurred in MyMethod.", ex);
}

Which will give you an error message and stacktrace. It's far more
useful to add state information to the logger so when you log that an
error occurred include any important local variables or argument
values.

My favorite example is .NET's type parsing errors--if you try to parse
an invalid value as an int or double or whatever it throws an error
saying the value is invalid but doesn't include the value in the error
text.

I agree with the previous poster re log4net--it may seem like overkill
for most use cases but it's easy to use and works very well.

Best regards,

Sam
 
Back
Top