Lesson 1: Using Exception Handling

The purpose of this lesson is to introduce "error" or "exception" handling in ASP.NET.

• "Errors that are not dealt with in code are called unhandled exceptions... There are three approaches to handling exceptions in a Web application..."

The three are: structured exception handling (SEH), error event procedures defined in the System.Web.UI.Page class and custom error pages declared in the @Page directive, its errorPage attribute.

• "You can combine approaches to effectively handle all possible exceptions within your application..."

• "Use exception handling structures to enclose statements that access nonmemory resources, such as files and database connections."

The use of the term "nonmemory resources" sounds strange. What is more perhaps is to say that try/catch/finally blocks are useful when crossing "boundaries" or "layers" in an application.

• "Use the Finally/finally block to include statements that are always executed before leaving the exception-handling structure."

The classic example for the above is closing a database connection when trying to connect to an external data source (and calling its Dispose() method).

• "The Microsoft .NET Framework includes specific exception types with the individual .NET Framework classes. This means that there is no single, comprehensive list of exception types in the .NET documentation. Instead, you must use the Visual Studio .NET Exceptions dialog box to view specific exception types..."

• "...you use the Throw/throw keyword to cause specific exceptions to occur."

The suggestion in the lesson is that exceptions can be used a primary form of communication instead of suggesting it for a secondary (or tertiary) form because of performance reasons. To the contrary, the lesson introduces the ApplicationException class to encourage us to define new exceptions based on this class.

• "The ApplicationException class provides the same features as the standard Exception class. It simply provides a way to differentiate between those exceptions defined in the .NET Framework and those defined in your application."

• "When an unhandled exception occurs in a Web application, ASP.NET fires the error events..."

These events are Page_Error, Global_Error and Application_Error. In the reality of Visual Studio .NET auto-generated code the Global_Error event procedure is not used.

• "Error events let you handle exceptions for an entire object in a single, centralized location---the error event procedure... When handling exceptions in error events, use the Server object to get information about the exception that occurred."

The Server.GetLastError() and Server.ClearError() methods gets "the information" and clears the error, respectively. The code samples suggest that a useful design pattern is to get the last error, store it in a Session variable, clear the error and use Server.Transfer() to re-load the page throwing the error.