ASP.NET 3.5 Enterprise Application Development with Visual Studio® 2008: Problem - Design - Solution

5.2. Design

Let's face it — even the most tested software with the most gifted programmers will have exceptions. It's impossible to think of every single scenario that a user may encounter when using your software. The system should be designed to handle unexpected exceptions even if Bill Gates himself is writing the application. Expected exceptions should be caught and handled gracefully. As mentioned in the introduction to this chapter, an example of an expected exception would be if a user tried to write to a read-only file. This kind of exception should be trapped in the specific method that is writing to the file and either try again or give the user a message to try again later.

The main focus of this chapter is unexpected exceptions. What should the application do when this occurs? Before getting on my soapbox about how these should be handled, let me first explain the options that the .NET Framework gives you for handling exceptions. Then I'll get into more specifics about how to use these options in the PaidTimeOff solution.

5.2.1. Application-Level Exception Handling

ASP.NET applications support handling all exceptions in a single event handler in the Global.asax file. When you add a Global.asax file to your application, an Application_Error event handler is automatically added to the file. This handler catches any unhandled exceptions that have been raised throughout the application. The event handler is as follows:

void Application_Error(object sender, EventArgs e) ...