Error Reporting Function Best Practices

Posted on 2007-07-20
Last Modified: 2010-04-15
Hello Experts
Currently I at the start and end of each function I have a try catch block to catch any errors which then calls a function to report any unhandled errors to our webservice.  Here is how we currently do it:

        private void SomeFunction()
            #region Try (ErrorReporting)
            #if !DEBUG

            // Code for function here
            #region Catch (ErrorReporting)
            #if !DEBUG
            catch (Exception Ex)

Can anyone think of a better way to handle this? or is the an effecient way of doing this?  We have the #ifdef !DEBUG so that it doesn't compile the error catching to make debuging easier. And the regions are there just so we can collapse the section because its real ugly code to look at in every routine :)

My question is what is your prefered method for catching errors and is there a more effecient method for us to use.  And secondly, is there a better method for catching than putting a try...catch in every function?

Question by:microbolt
    LVL 4

    Accepted Solution

    Exceptions are not a bad thing.  You can be opening yourself up to more problems the way you're doing things, because exceptions such as OutOfMemoryException and StackOverFlowException derive from Exception and catching them in this manner will be problematic.

    You should add exception handling blocks for specific exceptions in most cases.  Otherwise, let the exceptions fall through and catch them in the Application.ThreadException and/or AppDomain.UnhandledException.

    Another thing you might want to look at is the Exception Handling Block in the Enterprise Library.  It provides a very robust way of handling errors and allows you to setup policies that can be quite handy.

    One final point, an exception worth catching in a debug build is also worth catching in a release build.
    LVL 22

    Assisted Solution

    You can have the debugger break on exceptions, whether they are handled or not. From the main menu, Select Debugger/Exceptions. Then from the dialog, select the ones you want. Using this instead of catching exceptions you just rethrow not only save you tedious code, but it stops at the line of code that threw the exception, not just at the bottom of the method. And, all local variables are still in scope, so you can examine data-dependent kinds of problems easily. It also lets you see the call stack, so you can select the method that invoked this one to see where the bad data came from.

    In general, you should never catch an exception you do not need to handle in that method. Obvious exceptions to that rule exist. For example, there may be resources you need to dispose of cleanly to prevent leaks.

    We usually put our try - catch blocks at a very high level so we can log them and implement some graceful failure behavior. We use them at lower levels only to prevent leaks.
    LVL 22

    Expert Comment

    Also, Die-Tech's point :
    "One final point, an exception worth catching in a debug build is also worth catching in a release build."

    is very important. Leaks are more dangerous in Release builds where apps run a long time than they are in a 5 minute debugger session. And graceful failure handling is more important to you when your customers are running that release build.
    LVL 6

    Author Comment

    Good Stuff.  Exactly what I was looking for.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How to improve team productivity

    Quip adds documents, spreadsheets, and tasklists to your Slack experience
    - Elevate ideas to Quip docs
    - Share Quip docs in Slack
    - Get notified of changes to your docs
    - Available on iOS/Android/Desktop/Web
    - Online/Offline

    Exception Handling is in the core of any application that is able to dignify its name. In this article, I'll guide you through the process of writing a DRY (Don't Repeat Yourself) Exception Handling mechanism, using Aspect Oriented Programming.
    Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
    In this sixth video of the Xpdf series, we discuss and demonstrate the PDFtoPNG utility, which converts a multi-page PDF file to separate color, grayscale, or monochrome PNG files, creating one PNG file for each page in the PDF. It does this via a c…
    This video discusses moving either the default database or any database to a new volume.

    761 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    12 Experts available now in Live!

    Get 1:1 Help Now