I am experiencing some difficulties in managing errors raised from a custom REST web service deployed to SharePoint ISAPI folder I developed.

My service is pretty simple. I deployed an .svc file to the ISAPI folder, and configured the service to use the MultipleBaseAddressWebServiceHostFactory factory (the custom service is REST based).

<%@ ServiceHost Language="C#" Debug="true"
   Microsoft.SharePoint.Client.ServerRuntime, Version=, Culture=neutral, 
   PublicKeyToken=71e9bce111e9429c" %>

On the service I have a method configured as a WebInvoke operation:

[WebInvoke(Method = "POST", UriTemplate = "Foo?param1={param1}&param2={param2}&param3={param3}&param4={param4}")]
bool Foo(string param1, string param2, string param3, string param4)

My main issue is not begin able to correctly handle errors raised by the service (for sake of simplicity, let just assume the service method just throws a new ApplicationException, you will see why later).

If my service method throws an exception, the call seem to just return with status 200-OK, so jquery.ajax/angularjs $http think that the call has been successful and execute the promise success handler instead of the error one.

The only way I am able to actually have the error handler begin executed is if the exception I throw in my service inherits from SystemException: those exception seem to be handled in a different way and actually manage to trigger a 400 response. Still, in this case in my javascript error handler my error argument seem to be a string containing the SharePoint error page. I have confirmed by using the IE dev toolbar that in case of error, my service response body actually contains the full html source for the SharePoint error page.

I think I must be missing something obvious here. Can anyone provide help shedding some light on the issue? I would like to be able to receive just an error message from my service, just like SharePoint OOB REST services seem to be able to.

1 Answer 1


After some more experiment, I have discovered that by switching to use actual WebFaultException instances, I can bypass the "return a custom error page" SharePoint behavior and receive the actual error message from my JavaScript based client. This way, I can have an AngularJS app consume my web service via $http, while receiving a custom error message and status code.

A different case should be made for authorization related exceptions. Those seem to be handled in a different way. The only way I have found for now to be able to manually handle those is by temporally disabling a web app setting during the web service method execution. I will post more details as soon as I have them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.