Programming Microsoft ASP.NET 4 - Dino Esposito [144]
The overall design of Web controls is more abstract and much less tied to HTML. In general, Web controls do not promote a strict one-to-one correspondence between controls and HTML tags. However, the capabilities of Web and HTML controls overlap. All ASP.NET server controls render in HTML, but Web controls render to a more complex HTML representation than HTML controls.
In the next chapter, we’ll touch on programming issues that relate to authoring an ASP.NET page—error handling, localization, and personalization.
Chapter 7. Working with the Page
“Divide and rule, a sound motto. Unite and lead, a better one.”
—Wolfgang Goethe
Authoring an ASP.NET page is not simply a matter of putting together a well-organized hierarchy of server controls, literals, and JavaScript script blocks. That’s definitely a fundamental step, but it’s only the first step. First and foremost, a Web page is part of the presentation layer of a Web application. This means that the page is responsible for coordinating some user interface tasks aimed at providing end users with key information regarding bad requests and run-time anomalies, localized messages, and preferences.
Momentarily leaving aside any discussion on possible best practices for layering an ASP.NET Web Forms application, let’s examine some aspects related to ancillary page development tasks. Tasks covered in this chapter relate to error handling, error pages, tracing, localization, and personalization, as well as effective techniques to add script files and style the content of ages.
I’ll return to layers and design principles in Chapter 13.
Dealing with Errors in ASP.NET Pages
Any ASP.NET application can incur various types of errors. There are configuration errors caused by some invalid syntax or structure in one of the application’s web.config files and parser errors that occur when the syntax on a page is malformed. In addition, you can run into run-time errors that show up during the page’s execution. Finally, there are errors detected by the ASP.NET runtime infrastructure that have to do with bad requests or incorrect parameters.
Parser errors (both in configuration and markup) show up as soon as you start a debugging session, and their fix is immediate and part of the development process. What about other types of errors?
To prevent critical parts of your code from throwing exceptions at run time, you can resort to plain exception-handling practices as recommended by the Microsoft .NET Framework guidelines. To trap errors resulting from bad requests, invalid routing, or HTTP failures, you can take advantage of some of ASP.NET-specific facilities for page error handling.
Let’s attack the topic with a quick overview of exception handling as it happens in .NET.
Basics of Exception Handling
Just like other .NET applications, ASP.NET applications can take advantage of common language runtime (CLR) exceptions to catch and handle run-time errors that occur in the code. As a reminder, it’s worth mentioning here that in .NET development CLR exceptions are the recommended way of handling errors—they are the rule, not the exception!
Exceptions, though, should be taken just for what the name suggests—that is, events in the life of the application raised when something happens that violates an assumption.
Exceptions should not be used to control the normal flow of the program. If there is a way to detect possible inconsistent situations, by all means use that other method (mostly, conditional statements), and use exceptions as the last resort. The latest version of Microsoft Visual Studio 2010 (as well as many commercial products that assist you in development, such as JetBrains ReSharper and Telerik JustCode, to name a couple) offers coding tips and reminds you to check for possible null reference exceptions. That’s a huge help, isn’t it?
Although exceptions are the official tool to handle errors in .NET applications, they’re not free and should not be overused. Running any piece of code in a try/catch block will