The Server GetLast Error and Clear Error Methods

Early scripting languages had many problems. One of the worst was poor error handling. Fortunately, C#, with its Try-Catch blocks and structured exceptions, has gone a long way toward solving the problem. But there are still errors that you can't trap in code. For example, page preprocessing errors and compilation errors follow the default Internet Information Services (IIS) error-handling procedure. These errors don't (usually) crash ASP.NET—they can't—there may be many other applications that also depend on the server; therefore, Microsoft handles such errors by transferring execution to a default or custom ASP page. In Chapter 6, "Introduction to the System.Web Namespace," you saw how to define a global error page in the web.config file. You can also define custom error pages using the IIS management applet. In Windows 2000, click Start ® Programs ® Administrative Tools ® Internet Services Manager to launch the applet. The Internet Services Manager (ISM) applet runs as part of the Microsoft Management Console (MMC).

Without going into much detail on the ISM, here's the procedure to create a custom IIS error message:

1. Expand the item containing the name of your computer (there may be only one computer name visible).

2. Double-click the Default Web Site item.

3. In the resulting list of folders, find the CSharpASP application folder.

4. Right-click the CSharpASP application folder and select Properties from the context menu.

5. Click the Custom Errors tab.

You'll see a list of possible errors. Each entry in the HttpError column has a single number (for instance, 406) or an error number, a colon, and a suberror number (such as 500:15, read as "Error 500, sub-error 15"). Each error also has a type and an associated filename. You can replace the default file associated with an error with a custom ASP or ASPX file. Subsequently, IIS transfers execution to your custom file whenever the specified error occurs. If you're using a custom page, when an untrapped error occurs in your application, the server stores the error and transfers execution to the custom page. You can retrieve the error information using the Server.GetLastError method. For example:

Exception ex;

if (Server.GetLastError() != null) { ex = Server.GetLastError(); Response.Write(ex.Message);

You can also clear any stored error that may have occurred using the Server.ClearError method.

Note that neither of these methods is of much use when you're developing an application, especially locally. They're much more useful for presenting users with less intrusive and technical error messages and for debugging and pinpointing problems in deployed applications, especially from a remote machine, where web.config settings might prevent the error message from being displayed.

You'll explore the debugging process and error-handling process in detail in the next chapter. As part of the error-handling discussion, you'll set up a custom error page. You'll see how to set up your ASP.NET applications for debugging, and you'll learn more about the machine.config and web.config files and how to avoid many common ASP.NET errors.

Was this article helpful?

0 0

Post a comment