dotnet Exception Handling

.NET Exceptions – System.Web.HttpParseException

Making our way through our detailed .NET Exception Handling series, today we’ll be taking a closer look at the System.Web.HttpParseException. An HttpParseException should be thrown when something goes wrong while attempting to parse an HTML page.

In this article we’ll examine the HttpParseException by looking at where it resides in the overall .NET exception hierarchy. We’ll also go over a simple code sample that illustrates how one might use HttpParseExceptions in their own code, so let’s get to it!

The Technical Rundown

All .NET exceptions are derived classes of the System.Exception base class, or derived from another inherited class therein. The full exception hierarchy of this error is:

Full Code Sample

Below is the full code sample we’ll be using in this article. It can be copied and pasted if you’d like to play with the code yourself and see how everything works.

When Should You Use It?

The overall inner workings of ASP.NET pages are fairly complex, but to properly understand what the presence of an HttpParseException means we’ll just go over the simple basics of page creation. Specifically, we need a basic understanding of how .NET converts the XML-like content of ASP.NET pages (Web Forms) into executable .NET code.

Firstly, ASP.NET is a dynamically compiled language. Thus, when the first client request comes into the application all ASP.NET pages (.aspx), services (.asmx), handlers (.ashx), and global app files (.asax) are parsed by a PageParser. This is effectively an advanced text parser that recognizes the XML markup of ASP.NET pages. When a valid tag is recognized and parsed, that element is compiled into a normal .NET class instance, just like instances created in “normal” code. The parser and compiler work together to create the proper relationships between all controls and elements in the page, as well as across the entire application.

In short, this parsing and compilation process is where an HttpParseException can be thrown, when appropriate, to indicate that something about the parsing of the ASP.NET page has gone awry. A normal ASP.NET application is rather complex and difficult to fully include in text. Thus, our example code for this article shows the basic structure of creating a custom control and throwing an HttpParseException when necessary, without including all the fluff that would normally be in a full ASP.NET application.

We’re showing how we can force a custom HtmlSelect control to only contain our own custom dropdown option controls as child elements. Thus, we start with the MyCustomOption class, which is the option child control we want to add:

Now, the MySelectBuilder class inherits from the standard HtmlSelectBuilder, and will be used by our custom HtmlSelect control to check if child controls are of the appropriate type:

The GetChildControlType(string tagName, IDictionary attributes) method is overridden from the base HtmlSelectBuilder class and performs a basic logical check that child controls are of the MyCustomOption type. If not, a new HttpParseException is thrown, indicating that we only allow such child controls.

Finally, the actual CustomHtmlSelect class, which inherits from the standard HtmlSelect class and overrides just one method, AddParsedSubObject(object obj):

As the method name suggests, AddParsedSubObject(object obj) adds the parsed obj parameter control to the CustomHtmlSelect control. We’re explicitly casting from the passed obj object to MyCustomOption, which results in a null of the cast fails (hence, the nullibility check afterward). If successful, we know the parsed child object is of the proper MyCustomOption type, so we create some text and add the item to the Items list property.

With everything setup, we can now test things out. As mentioned, we’re foregoing the inclusion into a full ASP.NET application by just directly creating a builder and calling the GetChildControlType(string tagName, IDictionary attributes) method:

The GetChildControlOfControlBuilder(ControlBuilder builder, string tagName) method attempts to get the child control of the passed builder. If successful, it outputs some basic information about the builder and the type that was found as a child control. Otherwise, it catches expected or unexpected Exceptions.

We test this out by calling GetChildControlOfControlBuilder(ControlBuilder builder, string tagName) twice using a new MySelectBuilder instance. First, we check for child controls with a MyCustomOption.Suffix suffix, which works as expected and produces the following output:

However, our second attempt to get child controls with the Invalid suffix throws the expected HttpParseException, informing us that such child controls are invalid:

To get the most out of your own applications and to fully manage any and all .NET Exceptions, check out the Airbrake .NET Bug Handler, offering real-time alerts and instantaneous insight into what went wrong with your .NET code, along with built-in support for a variety of popular development integrations including: JIRA, GitHub, Bitbucket, and much more.