.NET Exceptions – System.Net.WebException

Moving along through our .NET Exception Handling series today we’ll take a closer look at the System.Net.WebException. While .NET provides numerous exceptions that are related to connectivity and web issues, the System.Net.WebException is one of the most generic (and thus most common) errors you’ll see in your own adventures.

Throughout this article we’ll dive into the System.Net.WebException in more detail and see where it sits within the .NET exception hierarchy. We’ll also look at a fully-functional C# code example to help illustrate how System.Net.WebExceptions might occur in day-to-day coding, so let’s get started!

The Technical Rundown

When Should You Use It?

Since .NET tends to feature far more complex (and specific) exception classes than simpler languages like Ruby or JavaScript, we usual with our System.Net.WebException exploration we’ll just start off by looking at the full example source code first and then we’ll walk through the major sections to see what’s going on:

We’re also using a few Utility namespace classes which we won’t explain here but feel free to check out the inline documentation for more info. Note that we’re also making use of the powerful AngleSharp HTML parser library, so be sure to add that reference to your project if you’re trying this yourself.

Since System.Net.WebExceptions are rather generic the basic purpose of our example script here is to send a WebRequest to a specific URI of our choice. If we’re able to successfully connect we then want to grab the HTML of the page in question using a WebResponse object. To simplify things so we don’t have to write everything from scratch we’re also using the AngleSharp parsing library to handle most of this work behind the scenes.

Therefore, all we really need to start is our WebParser class and the GetHtmlDocument() method that uses AngleSharp to try to connect to the provided uri string, get a response result, read the result as a string (which is the HTML of the page in this case), then parse that result to convert it to an IHtmlDocument which we’ll use later to extract some data from the page. The catch blocks in the GetHtmlDocument() method may seem a bit convoluted, but it ensures that we can capture any potential System.Net.WebExceptions that might be thrown.

Now we have a simple ParseTest() method that we use to perform our business logic. In this case we’re creating an IHtmlDocument object from the uri, querying the resulting HTML to get all major header elements (h1 and h2), extracting the text content of those headers, and then splitting the headers up into an array. This just serves as a simple example of creating a remote web connection and parsing the HTML for some info we want. The last step is to output the title of the page and the headers we collected to our log:

To see this in action we have two different URIs we want to try in our ParseTest() method:

For our first test we’re trying to connect to the homepage and, as you might suspect, everything goes as planned. We were able to connect and gather the title of the page and the main header values, which is indicated by the log output of our script:

Sure enough if we manually open the homepage in a browser window we can confirm that the title and main headers all match what our application collected — cool!

However, our second ParseTest() call attempts to connect to a localhost port that my development machine doesn’t have open, so we invariably produce a number of errors. Most of those exceptions are actually contained within a System.AggregateException instance, which is why we needed the complicated method of exception extraction to see what actual exception object types we’re getting by digging into the InnerException property.

Therefore, as it happens — in addition to a few other exception types — we also end up catching a System.Net.WebException, as seen in the log output:

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.