Apparently, I can throw an HttpResponseException inside a controller action by sticking a 200 HttpResponseMessage into it.

    public class CarsController : ApiController {

        public string[] GetCars() {

            //throw the HttpResponseException
            var response = new HttpResponseMessage(HttpStatusCode.OK);
            throw new HttpResponseException(response);
            
        }
    }

And this gives me a 200 response back as result.

I see that the ApiControllerActionInvoker inspects the exception thrown inside the controller and if the exception type is HttpResponseException, it sets its Response property and passes it onto its caller.

Do u think that this is right? I mean it is all developer's fault if s/he throws an HttpResponseException with a successful status code but do u think the framework should do something to prevent it from going over the wire?

It is by design :) An HttpResponseException is designed to allow you to stop whatever you are doing at any point while processing a request and create any HttpResponseMessage to reflect the status of processing the request. From the outside, HTTP of course doesn't care about internal details such as exceptions so it doesn't care how a response is generated nor whether it is successful or an error.

Hope this helps,

Henrik

Ok, that's a fair answer.

In my controller when I want to stop whatever I am doing, I can always return the HttpResponseMessage, if the controller action return expression type is HttpResponseMessage. So, I am assuming HttpResponseException is mainly intended to be used inside a controller action where the return expression type is different than HttpResponseMessage.

I have seen Darrel Miller has resurrected HttpResponseMessage<T> in a new body in some shape or form (I canot remember where I had seen it)! I think that is the ultimate compromise, ability to have the HTTP richness while keeping API meaningful to C# clients.

I know the problem was inability to guarantee the type through the pipeline, but it is useful to have.

<<For some reason doubly posted>>

@tugberk,  @aliostad returning HttpResponseMessage is different than throwing an HttpResponseException. When you throw the exception the response you passed to the exception is immediately returned. Processing stops and no filters or handlers are executed. Basically you are saying immediately exit and return this. When you return HttpResponseMessage however the response continues being fully processed ie handlers and filters execute.

Aside from that the other reason as you observed is if the payload is not typed / uses a different type in the case of an exception. In the past we used to have HttpResponseMessage<T> that you could return and in those cases it was very common to want to just return a message with a string payload for error cases. We've removed HttpResponseMessage<T> now so that is less of an issue.

I talk about the differences between both in this post.

@gblock

Thanks for the detailed answer Glenn.

Sure thing, glad it helped.