Effective Error Handling with WCF & REST

The post on effective error handling with WCF and REST has been moved to my new blog at www.robbagby.com.


Comments (7)
  1. Anonymous says:

    Thank you for submitting this cool story – Trackback from DotNetShoutout

  2. Anonymous says:

    #.think.in infoDose #18 (26th Jan – 20th Feb)

  3. cheeso says:

    Hey bags? how are you?  Nice example.  re: your comment that "defaults change":  I actually think the 500 error is reasonable to return.  If a service throws, then the standard ServiceHost treats it as an exception on the server side.  Totally reasonable for the WebServiceHost2 to do that. The behavior of WebServiceHost seems surprising.

  4. Garry Trinder says:

    Things are good!  Thanks for asking.

    In some cases the 500 is good, in others a 400 is more appropriate.  My example was that someone requested a page with a size of 0 or negative.  That is not really a server error, rather a bad request.  If you were not sure what went wrong in this case and were handed a 500, you might think that the service had an issue, when the issue was with your request.  

    The net-net is that either default will be wrong in certain cases.  You need to control it yourself.

    Hope all is well with you…


  5. Anonymous says:

    Thanks  for sharing this useful info

  6. Anonymous says:


    So if I have the following GET:

    GET http://DomainName/MyService.svc/Products?ProductId=

    Notice the "ProductId=". This will result in the following error. Is there a way to catch it and return a Bad Request stating that the ProductId was missing in the Querystring?

    400 – Bad Request.

    The server encountered an error processing the request. Please see the service help page.

Comments are closed.

Skip to main content