This post wasn’t part of the original series, but I have decided to add it because of a project I am working on these days.

Most of the times I have been involved in the server side of web services, developing web services, but in this opportunity I am consumer of web services.

When reviewing the technical specs of the web services I have to consume I found that each web service returned a complex type that contains the following fields:

• Result: an integer that represents the result of the invocation, (1) successful invocation, (2) Invalid parameters, (3) Internal service error, and so on.
• Errors: in case the result be (2) it details the name of the parameters that are not valid.
• Data: the business information expected as the result of the invocation.

This approach is not bad, but I feel it like been reinventing the wheel. Maybe it is because of my object-oriented programming background. I am used to use exceptions to handle errors. Most of the technologies that give support to soap protocol provides a way to work  with exceptions to manage errors.

When you call a web service and an error raises during the process, a soap fault message should be used to communicate the error. This fault message contains:

• Code: that allows the fault to be classified in one of the following categories: VersionMismatch, MustUnderstand, DataEncodingUnknown, Sender and Receiver.
• Reason: provides a human-readable explanation of the fault
• Node: provides information about which SOAP node on the SOAP message path caused the fault to happen
• Role: identifies the role the node was operating in at the point the fault occurred.
• Detail: is intended for carrying application specific error information

No matter what technology you used to work with SOAP, most of them provide a class to represent a Soap Fault, that is typically called Soap Exception. In the case of .NET there is a SoapException. This way if you are using .NET to consume a web service using Soap, .NET will generate a proxy object for you to call the web service, when you call this service you should do it inside a try-catch block adding 2 catch statements one catch for a SoapException and another catch statement for a System.Net.WebException, in case that no connectivity can’t be established.