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.