[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Error Reporting Function Best Practices

Posted on 2007-07-20
4
Medium Priority
?
266 Views
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
            try
            {
            #endif
            #endregion

            // Code for function here
           
            #region Catch (ErrorReporting)
            #if !DEBUG
            }
            catch (Exception Ex)
            {
                DefaultErrorHandling(Ex);
            }
            #endif
            #endregion
        }

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?

Thanks!
0
Comment
Question by:microbolt
  • 2
4 Comments
 
LVL 4

Accepted Solution

by:
Die-Tech earned 260 total points
ID: 19536446
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.
0
 
LVL 22

Assisted Solution

by:JimBrandley
JimBrandley earned 240 total points
ID: 19536864
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.
0
 
LVL 22

Expert Comment

by:JimBrandley
ID: 19536873
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.
0
 
LVL 6

Author Comment

by:microbolt
ID: 19536995
Good Stuff.  Exactly what I was looking for.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In order to hide the "ugly" records selectors (triangles) in the rowheaders, here are some suggestions. Microsoft doesn't have a direct method/property to do it. You can only hide the rowheader column. First solution, the easy way The first sol…
Introduction This article series is supposed to shed some light on the use of IDisposable and objects that inherit from it. In essence, a more apt title for this article would be: using (IDisposable) {}. I’m just not sure how many people would ge…
this video summaries big data hadoop online training demo (http://onlineitguru.com/big-data-hadoop-online-training-placement.html) , and covers basics in big data hadoop .
With just a little bit of  SQL and VBA, many doors open to cool things like synchronize a list box to display data relevant to other information on a form.  If you have never written code or looked at an SQL statement before, no problem! ...  give i…
Suggested Courses

830 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