Question

I’m creating an HTTP API using ASP.NET Web API. I’ve noticed that if an exception occurs that I haven’t handled, that behaviour is very different to if I deliberately throw an HttpResponseException. This will make it hard for clients to reliably handle an error and display the “reason” message.

Eg consider this code:

[HttpPost]
public void ThisWillThrowAnError()
{
    try
    {
        var i = 0;
        var b = 1 / i; // cause divide by zero exception for testing
    }
    catch (Exception ex)
    {
        HttpResponseMessage message = new HttpResponseMessage();
        message.ReasonPhrase = "Error: " + ex.Message;
        throw new HttpResponseException(message);
    }
}

This creates a response which has the error in an HTTP header and the response code set to 500:
Error: This request could not be processed. Attempted to divide by zero.

The actual response body is empty.

However if I remove the try/catch block, or if an exception occurs for which I do not manually throw an HttpResponseException, I get totally different behaviour. Although the status code is still 500, the header message just says “Internal Server Error” and the message is encoded in a JSON format like this:

{
  "Message": "An error has occurred.",
  "ExceptionMessage": "Attempted to divide by zero.",
  "ExceptionType": "System.DivideByZeroException",
  "StackTrace": " at ProjectName.Controllers (etc....)"
}

I think I prefer the latter as it gives you more info for debugging but it removes the ability to customise the message or provide a user-readable message for the problem.

Why is WebAPI inconsistent with how it handles exceptions? Am I doing something myself to cause this inconsistency? It just seems rather messy and difficult to work with and may mean that the calling application will have to be coded to handle two different types of error response 🙁

Answer 1

When creating error responses, consider using HttpRequestMessage.CreateErrorResponse to create error responses that are consistent with the ones WebAPI sends.

This blog post should hopefully help:
http://blogs.msdn.com/b/youssefm/archive/2012/06/28/error-handling-in-asp-net-webapi.aspx