System.Threading.ThreadAbortException

.NET Exceptions – System.ServiceModel.FaultException

Moving along through our .NET Exception Handling series today we’re going to take a gander at the System.ServiceModel.FaultException. The System.ServiceModel.FaultException is the first error we’ve dealt with in this series that is tied directly to the Windows Communication Foundation (WCF) platform of services. These services act as a remote interface, such as an API, that can be accessed by clients and other applications to perform some actions, without the client knowing about the underlying logic of the service.

In this article we’ll dig into just what the System.ServiceModel.FaultException is including where it sits in the .NET exception hierarchy. We’ll also explore some functional C# code examples which will illustrate how System.ServiceModel.FaultExceptions are thrown and how to properly handle them, so let’s get started!

The Technical Rundown

When Should You Use It?

Working with WCF services can be a little confusing compared to “normal”, localized code, so we’ll start out with the full working code example and then walk through it afterward:

Ignoring our Utility functions for logging, our service application example consists of three basic components: An ILibraryService interface, a LibraryService class, and then a LibraryClient that uses the service to make something happen. Therefore we start with a basic (albeit very simple) service interface:

Here we’re using a lot of [attributes] to specify the expected behavior of our service interface. We really just have one invokable service method called ReserveBook, which finds a book by title and author before trying to reserve it. What’s particularly important here is the InvalidBookFault class, which we use to communicate the potential error from the LibraryService to our client. This allows the client to be informed of what specifically went wrong.

Next is our LibraryService class which implements the ILibraryService interface. To make things a bit more interesting we’ve specified that the ReserveBook() method should be provided valid title and author argument strings, otherwise it’ll throw an ArgumentException error. However, this is still all “server-side” so we need to catch the produced ArgumentException and generate a contractual fault that can be relayed to the invoking client. This is where our previously-defined InvalidBookFault comes into play. Within the ArgumentException catch we create a new InvalidBookFault instance, populate it with values from our exception (such as the basic error message), then throw a new FaultException<InvalidBookFault>:

Finally our simple LibraryClient application actually invokes our LibraryService (via a service reference in Visual Studio) to acquire a client connection. From this we can open the connection and then call the ReserveBook() service method:

We begin with a valid set of title and author arguments for our first ReserveBook() call, so the result is as expected and our service “reserves” our book for us as show in the output:

However, the second ReserveBook() call includes a null value for the second argument. As you’ll recall this isn’t acceptable and triggers our chain of exception and fault events: The LibraryService throws a new ArgumentException, which is caught and then creates and throws a new InvalidBookFault. Our LibraryClient then catches the FaultException<LibraryServiceReference.ArgumentExceptionFault> and can safely report that issue to the end-user/client, as we see in the output:

We’ve successfully created a System.ServiceModel.FaultException of type LibraryClient.LibraryServiceReference.InvalidBookFault and it’s populated by relevant error information that came from our service. This powerful technique allows clients and services to securely communicate exception information without breaking any contracts.

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.