Logging Error Best Practices

  • Thread starter Thread starter Chris
  • Start date Start date
C

Chris

I've got a logging routine on my client that logs
errors. I'm hoping to use this error information for
debugging purposes during testing and then during
production. I want to log these exceptions at the best
place possible to help me in this goal. Where should I
put these try / catch blocks?

Currently I'm placing them around all form events where
I'm doing anything non-trival. Is this too much? Would
love to hear you suggestions.

Thanks,
Chris
 
Chris,

There is no such thing as too much error handling.

For some of our applications, we've created a MS-Office style "watson"
system where if an unrecoverable exception occurs, we prompt the user for
any additional information and then send the exception details to our
universal logging web service that we keep for all applications. FWIW...

Also, there's an Exception Handling & Error Reporting application block
available on the Microsoft Patterns & Practices web site.

Brandon
 
Thanks guys, but what I asked was where should I put the
try / catch blocks? Right now I've got try / catch
blocks around all possible code from user interaction and
form events.

I read that article before implementing my solution, but
I instead decided to go with a solution found in the
book "Distributed Applications - Microsoft Press".

Once again, thanks for the input,
Chris
 
Chris,

It's just common sense. Put a try/catch block around anything that depends
on something that could fail. i.e., calls to Active Directory, calls to
write files that require specific permissions, calls to services across a
network / web services, etc. Obviously there's not really a point to put a
try/catch block around changing the text of a label, title of a window, or a
well written and controlled For or While loop, etc.

For example, if I am expecting integers in TextBox1 and TextBox2, and I'm
writing a function to add them together, it would be a good idea to have the
code check for:

A) Is there anything in the textbox? (is length > 0?)
B) Is what's in the text box actually a number?
C) Is that number within the constraints of my usage? (fits into an int?)

etc, etc, etc.

If you can hit the right combination of putting the try/catch blocks around
your real failure points, and code smart, efficiently, and robustly (is that
word? eh, you get it), then you'll be good to go.

Brandon
 
I finally broke down and wrote the following:

/// <summary>
/// Delegate describing methods to be invoked by the InvokeUIAction method
/// </summary>
public delegate void UIActionHandler(object sender, EventArgs e);

/// <summary>
/// Invoke a UI action, trapping exceptions and displaying the watch
cursor
/// </summary>
/// <param name="ctl">The container control</param>
/// <param name="action">The UIActionHandler delegate to invoke</param>
/// <param name="sender">The object triggering the action</param>
/// <param name="e">The EventArgs instance which came with the
trigger</param>
/// <returns>The duration of the action</returns>
public static TimeSpan InvokeUIAction(ContainerControl ctl,
UIActionHandler action, object sender, EventArgs e)
{
DateTime startTime = DateTime.Now;

Cursor saveCursor = ctl.Cursor;
ctl.Cursor = Cursors.WaitCursor;

try
{
action(sender, e);
}
catch (Exception ex)
{
ExceptionBox.DisplayException(ex, "Exception in UI action");
}
finally
{
ctl.Cursor = saveCursor;
}

return DateTime.Now.Subtract(startTime);
}

Now, any of my UI events will look strange if I don't do something like
this:

private void btnOk_Click(object sender, EventArgs e)
{
FormsLibraryUtil.InvokeUIAction(this, new UIActionHandler(Do_Ok),
sender, e);
}

private void Do_Ok(object sender, EventArgs e)
{
...
}
 
Back
Top