Error code or Exception - which is the best practice for an ASP.Net web service?

Question

I've read this thread for WCF has inbuilt Custom Fault codes and stuff.

But what is the best practice for ASP.Net web services? Do I throw exceptions and let the client handle the exception or send an Error code (success, failure etc) that the client would rely upon to do its processing.

Update: Just to discuss further in case of SOAP, let's say the client makes a web svc call which is supposed to be a notification message (no return value expected), so everything goes smooth and no exceptions are thrown by the svc.

Now how will the client know if the notification call has gotten lost due to a communication/network problem or something in between the server and the client? compare this with not having any exception thrown. Client might assume it's a success. But it's not. The call got lost somewhere.

Does send a 'success' error code ensures to the client that the call went smooth? is there any other way to achieve this or is the scenario above even possible?

Answer 1

Jeff Atwood posted an interesting aerticle about this subject some time ago. Allthough a .NET exception is converted to a SoapFault, which is compatible with most other toolkits, the information in the faults isn't very good. Therefor, the conlusion of the article is that .NET webservices don't throw very good exception messages and you should add additional information:

Private Sub WebServiceExceptionHandler(ByVal ex As Exception)
    Dim ueh As New AspUnhandledExceptionHandler
    ueh.HandleException(ex)

    '-- Build the detail element of the SOAP fault.
    Dim doc As New System.Xml.XmlDocument
    Dim node As System.Xml.XmlNode = doc.CreateNode(XmlNodeType.Element, _
        SoapException.DetailElementName.Name, _
        SoapException.DetailElementName.Namespace)

    '-- append our error detail string to the SOAP detail element
    Dim details As System.Xml.XmlNode = doc.CreateNode(XmlNodeType.Element, _
        "ExceptionInfo", _
        SoapException.DetailElementName.Namespace)
    details.InnerText = ueh.ExceptionToString(ex)
    node.AppendChild(details)

    '-- re-throw the exception so we can package additional info
    Throw New SoapException("Unhandled Exception: " & ex.Message, _
        SoapException.ClientFaultCode, _
        Context.Request.Url.ToString, node)
End Sub

More info why soapfaults are better in this question.

Answer 2

Depends on how you are going to consume the web service - i.e. which protocol are you going to use.

If it is GET or POST, better return error code, as the calling HttpWebRequest (.Net) or other code will receive server error, and have to deal with it to extract the exception code.

If it is SOAP - then it is perfectly ok to throw custom exceptions (you do not want to return internal framework exceptions, as they may reveal some stack trace, etc. to external parties).

As the SOAP web services are exactly meant to look to the calling code as a normal method call, the corresponding calling framework should be able to handle and propagate the exception just fine, thus making the calling code look and behave as it deals with internal calls.