@digitalpacman's previous post:
>>If you think that it's not good design, how are you supposed to return a typed error response that is different than what you register your output to be?
That's kind of my point. I would argue you want to be able to return expected failures without having to throw an exception to it. With the current implementation, the only way to do this is to have every response type carry the ability to report a failure
condition. You could do this with a type hierarchy:
class ErrorResponse : ResponseBase
class SomeGoodResponse : ResponseBase
and return HttpResponseMessage<ResponseBase> from every method. But that's uuuuuuuuuuuuuugggggly!
Maybe HttpResponseMessage<TSuccess, TFail> would do it so you have a choice of setting two different Content properties, one for success, one for failure. I'm sure there's a better way than this... but I'm not sure throwing exceptions as control flow
As an example, let's say I had a web site that sold rare items and an API that you could use to reserve an item. Maybe it has the signature:
HttpResponse<ItemReservation> CreateReservation(int itemId)
Now it's highly likely that users may find that they've been beaten to the punch by someone else. In this case, throwing an exception to be caught by an error handler to send a different response (maybe an HttpResponse<ItemReservationFailed>) to convey
the failure would be nasty. So do I have to add structure to all my return types to carry failure information?