Easy way to catch all unhandled exceptions in C#.NET

Question

I have a website built in C#.NET that tends to produce a fairly steady stream of SQL timeouts from various user controls and I want to easily pop some code in to catch all unhandled exceptions and send them to something that can log them and display a friendly message to the user.

How do I, through minimal effort, catch all unhandled exceptions?

this question seems to say it's impossible, but that doesn't make sense to me (and it's about .NET 1.1 in windows apps):

Answer 1

All unhandled exceptions finally passed through Application_Error in global.asax. So, to give general exception message or do logging operations, see Application_Error.

Answer 2

If you need to catch exeptions in all threads the best aproach is to implement UnhandledExceptionModule and add it to you application look here for an example

Answer 3

Use the Application_Error method in your Global.asax file. Inside your Application_Error method implementation call Server.GetLastError(), log the details of the exception returned by Server.GetLastError() however you wish.

e.g.

void Application_Error(object sender, EventArgs e) 
{ 
    // Code that runs when an unhandled error occurs
    log4net.ILog log = log4net.LogManager.GetLogger(typeof(object));
    using (log4net.NDC.Push(this.User.Identity.Name))
    {
        log.Fatal("Unhandled Exception", Server.GetLastError());
    }
}

Don't pay too much attention to the log4net stuff, Server.GetLastError() is the most useful bit, log the details however you prefer.

Answer 4

The ELMAH project sounds worth a try, its list of features include:

ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.

• Logging of nearly all unhandled exceptions.
• A web page to remotely view the entire log of recoded exceptions.
• A web page to remotely view the full details of any one logged exception.
• In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrors mode turned off.
• An e-mail notification of each error at the time it occurs.
• An RSS feed of the last 15 errors from the log.
• A number of backing storage implementations for the log

More on using ELMAH from dotnetslackers

Answer 5

You can subscribe to the AppDomain.CurrentDomain.UnhandledException event.

Answer 6

It's probably important to note that you are not supposed to catch unhandled exceptions. If you are having SQL timeout issues, you should specifically catch those.

Answer 7

Do you mean handling it in all threads, including ones created by third-party code? Within "known" threads just catch Exception at the top of the stack.

Answer 8

Timeout errors typically occur if you are not forcefully closing your sqlconnections.

so if you had a

try {
    conn.Open();
    cmd.ExecuteReader();
    conn.Close();
} catch (SqlException ex) {
    //do whatever
}

If anything goes wrong with that ExecuteReader your connection will not be closed. Always add a finally block.

try {
    conn.Open();
    cmd.ExecuteReader();
    conn.Close();
} catch (SqlException ex) {
    //do whatever
} finally {
    if(conn.State != ConnectionState.Closed)
       conn.Close();
}

Answer 9

One short answer is to use (Anonymous) delegate methods with common handling code when the delegate is invoked.

Background: If you have targeted the weak points, or have some boilerplate error handling code you need to universally apply to a particular class of problem, and you don't want to write the same try..catch for every invocation location, (such as updating a specific control on every page, etc).

Case study: A pain point is web forms and saving data to the database. We have a control that displays the saved status to the user, and we wanted to have common error handling code as well as common display without copy-pasting-reuse in every page. Also, each page did it's own thing in it's own way, so the only really common part of the code was the error handling and display.

Now, before being slammed, this is no replacement for a data-access layer and data access code. That's all still assumed to exist, good n-tier separation, etc. This code is UI-layer specific to allow us to write clean UI code and not repeat ourselves. We're big believers in not quashing exceptions, but certain exceptions shouldn't necessitate the user getting a generic error page and losing their work. There will be sql timeouts, servers go down, deadlocks, etc.

A Solution: The way we did it was to pass an anonymous delegate to a method on a custom control and essentially inject the try block using anonymous delegates.

// normal form code.
private void Save()
{
    // you can do stuff before and after. normal scoping rules apply
    saveControl.InvokeSave(
        delegate
        {
            // everywhere the save control is used, this code is different
            // but the class of errors and the stage we are catching them at
            // is the same
            DataContext.SomeStoredProcedure();
            DataContext.SomeOtherStoredProcedure();
            DataContext.SubmitChanges();
        });
}

The SaveControl itself has the method like:

public delegate void SaveControlDelegate();

public void InvokeSave(SaveControlDelegate saveControlDelegate)
{        
    // I've changed the code from our code. 
    // You'll have to make up your own logic.
    // this just gives an idea of common handling.
    retryButton.Visible = false;
    try
    {
        saveControlDelegate.Invoke();
    }
    catch (SqlTimeoutException ex)
    {
        // perform other logic here.
        statusLabel.Text = "The server took too long to respond.";
        retryButton.Visible = true;
        LogSqlTimeoutOnSave(ex);
    }
    // catch other exceptions as necessary. i.e.
    // detect deadlocks
    catch (Exception ex)
    {
        statusLabel.Text = "An unknown Error occurred";
        LogGenericExceptionOnSave(ex);
    }
    SetSavedStatus();
}

---

• There are other ways to achieve this (e.g. common base class, intefaces), but in our case this had the best fit.
• This isn't a replacement to a great tool such as Elmah for logging all unhandled exceptions. This is a targeted approach to handling certain exceptions in a standard manner.

Answer 10

I'd recommend looking at log4net and seeing if that's suitable for the logging part of the question.

Answer 11

If using .net 2.0 framework, I use the built in Health Monitoring services. There's a nice article describing this method here: https://web.archive.org/web/20210305134220/https://aspnet.4guysfromrolla.com/articles/031407-1.aspx

If you're stuck with the 1.0 framework, I would use ELMAH: http://msdn.microsoft.com/en-us/library/aa479332.aspx

hope this helps

Answer 12

There are 2 parts to this problem handling & identifying.

Identifying

This is what you do when the exception is finally caught, not necessarily where it is thrown. So the exception at that stage must have enough context information for you to idenitfy what the problem was

Handling

For handling, you can a) add a HttpModeule. See http://www.eggheadcafe.com/articles/20060305.asp I would suggest this approach only when there is absolutely no context informaatn available and there might be issuus wiih IIS/aspnet, In short for catastrophic situations

b) Create a abstract class called AbstractBasePage which derives from Page class and have all your codebehind classes derive from AbstractBasePage

The AbstractBasePage can implement that Page.Error delegate so that all exceptions which percolate up through the n-tier architecture can be caught here(and possibly logged)

I would suggest this cause for the kind of exceptions you are talking about (SQlException) there is enough context information for you to identify that it was a timeout and take possible action. This action might include redirecting user to a custom error page with appropriate message for each different kind of exception (Sql, webservice, async call timeouts etc).

Thanks RVZ

Answer 13

This is old question, but the best method (for me) is not listed here. So here we are:

ExceptionFilterAttribute is nice and easy solution for me. Source: http://weblogs.asp.net/fredriknormen/asp-net-web-api-exception-handling.

public class ExceptionHandlingAttribute : ExceptionFilterAttribute
{
    public override void OnException(HttpActionExecutedContext context)
    {
        var exception = context.Exception;
        if(exception is SqlTimeoutException)
        {
            //do some handling for this type of exception
        }
    }
}

And attach it to f.e. HomeController:

[ExceptionHandling]
public class HomeController: Controller
{

}