HTTP status code in WCF using error handling

HTTP status code in WCF using error handling

While the Web.API available on Codeplex in many ways seems like an excellent framework for building REST-full webservices on top of WCF and .NET I recently tried to dive into the plain WCF-framework and look at the extension points available with the purpose of building a REST service directly on top of WCF.

One of the interesting and simple possibilites is to use standard WCF error handling to capture exceptions and map them to http status types. Of course this should only be a part of the exception strategy, but it is certainly usefull and makes it possible to avoid a lot of repetitive try-catch blocks. This in it self is naturally a cool feature and useful whether or not the service being implemented is aiming for REST or any other component.

The building blocks are as follows:

  • An IErrorHandler implementation that takes care of catching exceptions and perform the wanted logic operations.
  • A service behavior which injects the error handler into the WCF call stack. (Note that while we are only discussing one single error handler it would be possible to create operation behaviors and bind the exception logic by a method decorator instead.)
  • An attribute for decorating the service and binding the service behavior
  • Some kind of mapping between application exceptions and http status codes.
Service behavior
The simplest possible example would be to map a common exception handler to all methods of a service. The error handler should be added to the ChannelDispatcher in service behavior.

This can be obtained with a class similar to the one below. It is simply an attribute that decorates the service implementation and injects an error handler of typeMappingErrorHandler into the dispatcher:

The validate method should be implemented to make it more robust. In this example we assume everything is bound to the webHttpBinding so it would be wise to test if this binding was actually enabled, and of course other tests derived from the actual logics could be implemented.

Implementing the IErrorHandler interface is also very straight forward. The example below simply tests if an exception is a mapped type in a large yucky if statement and translates the two known types into http status codes. The boolean HandleError returns true if the exception is an ApplicationException; this is what this simple handler is designed to handle.

To add the error handler to a service, we simply decorate the service implementation with the attribute. So assuming the service contract below

with an implementation

will cause all requests to be translated to status codes as described in the exception mapper.


This Post Has 2 Comments

  1. Hello,

    The only problem with using http status codes for error handling is, you can’t change the header once the body has eben started. So you can only match exceptions occuring before data is written.


    1. Hey Florian – The scenario envisioned here is indeed to catch business exceptions and translate them into status codes; we enclose the entire service implementation and convert errors thrown by the methods which will happen before any data is being sent to the WCF formatters. If errors happens during data conversion they will be handled by WCF and outside our control. But I would like to hear your thoughts on when this would happen.
      Thanks for your comment! :)

Leave a Reply

Close Menu