ASP.NET: Adding Error Handling With Email Notifications

If you're developing a new application, the temptation is often to get it completed and deployed in the shortest time possible. And sometimes that may come at the expense of proper error handling. So with the best will in the world, sometimes problems do occur in a Production database and the users see an error.

And with no error handling in your application, that can be a pretty poor experience for the user which can make you look a bit unprofessional and can potentially expose your application to security issues if your settings allow the user to see the Exception Details Yellow Screen of Death. So after I completed a deployment of a major release, I decided it was time to implement some error handling and to enable my application to automatically email me with details of any errors which occurred in Production.

One of the things think is brilliant about .NET is the documentation. It's terrific. There are tutorials on every subject, and error handling within ASP.NET is very well covered. So basically, the steps to implement are as follows:

1. Add a custom error page with the appropriate look and feel
Rather than me plagiarise the tutorials on the official ASP.NET web site, here's a link to a tutorial which explains the concepts involved and will get you up and running with a custom error page which, depending on the type of error, shows a nice message to your users, rather than the Yellow Screen of Death (YSOD):



2. Add a Global.asax file to enable application-wide error handling
If you followed the tutorial above, when an error occurs the user sees a nicely formatted error message which is in keeping with the rest of your application. But nothing is really done about the error. It's equally important that you are notified of the error, and that you can investigate it with a view to resolving it.

So the next step is to enable your ASP.NET application to catch any errors, application wide. This is done by adding a Global.asax file which has event handlers for various different application wide events, including trapping errors. The next tutorial from the ASP.NET website explains the concepts involved and helps you to get an error handler set up. It also shows you how to automatically notify you via email when an error occurs.

Remember, when pasting any code from the example into your project that you need to import System.Net.Mail at the top of your Global.asax page in order to identify the appropriate classes for sending mail. You also need to add the appropriate mail server settings to your web.config file (you might need to specify a port number and username and password):

<system.net>
<mailSettings>
<smtp>
<network host="mailhost.*****.net" />
</smtp>
</mailSettings>
</system.net>

So now if you've done things by the book, you should be set up to be automatically notified of the details of any errors which occur, and the users should see a nice friendly screen rather than the horrible YSOD.

Finally, I'm a big fan of using XML for configuration settings where possible, rather than hard-coding them into the application. So you can add some keys to your web.config file which contain the settings you want to use for your email notifications. You could add something like this to appSettings inside your web.config:

<!-- Settings used for email error notifications -->
<add key="ErrorToAddress" value="support@example.com"/>
<add key="ErrorFromAddress" value="aspApp@ example.com"/>
<add key="ErrorEmailSubject" value=" aspApp: An error has been logged"/>

Then, in your Global.asax file, replace the hard coded values with a call to extract these settings from your web.config:

' Get the appropriate values from the web.config file
Dim ToAddress As String = ConfigurationManager.AppSettings("ErrorToAddress")
Dim FromAddress As String = ConfigurationManager.AppSettings("ErrorFromAddress")
Dim Subject As String = ConfigurationManager.AppSettings("ErrorEmailSubject")

This all worked for me, and now my application is more robust, the users don't see any horrible error messages and if any problems occur in Production I'll know about it pretty quickly.

Hopefully, this might help you to consolidate the necessary parts of what's required to implement some error handling within your application too. But of course, this is no replacement for using proper try-catch error handling where appropriate.