Question

I log exceptions with Elmah and was wondering if the technique I am using is good design?

Right now I catch and re throw exceptions that occur in various classes and methods, and log them to Elmah in the main try-catch block of the program.

// Main Program

try
{
   // Some code that fires off other classes, etc...
   MyTestClass myTestClass = new MyTestClass();
   myTestClass.Execute();   

}
catch(Exception ex)
{
   ErrorSignal.FromCurrentContext().Raise(ex);
}

// MyTestClass

    public class MyTestClass
    {
        public object ApiResult { get; set; }


        public string Execute()
        {            
            try
            {
                // execute some code
                // ....
                // set xml message
                ApiResult = "User information xml response";
            }
            catch (Exception ex)
            {
                // set xml message
                ApiResult = "something went wrong xml error response...";

                throw;
            }
        }

    }

Would it be better to log the exceptions where they occur? Another question, should I log errors that I can handle without catching exceptions? For example if something is null, should I do a test for that (if null…) and log a message in Elmah?

Answer 1

Rather than manually logging an error using Elmah’s ErrorSignal class you should instead strive to let ELMAH log errors for you automatically, which occurs when the application’s Error event is raised.

In your example there’s a serious problem with Main Program. Namely, it is swallowing exceptions, at least for the end user. Yes, the exception is getting logged in ELMAH but you are hiding the error from the user. The end user will think her form submission (or whatever) went through without error, when in actuality there was a grave problem.

In short, try...catch blocks should only be used sparingly, such as in cases where you can recover from an error or when the error is a “minor” one and should not stop the workflow. But the majority of errors are real show stoppers and don’t have graceful workaround. For this majority you’d want to let the error percolate up to the ASP.NET runtime where ELMAH will automatically log it and where the user will see an error page, alerted them to the fact that an error has occurred.

Check out this article of mine: Exception Handling Advice for ASP.NET Web Applications.