I am looking at implementing a Web Service API for our product. I have figured out how you go about the general architecture/fault handling within WCF. My question is a more general one of how to design the overall error handling system. For example I have a method called SaveCompany(companyobject). Each company name needs to be unique. Say you tried to save a second company called “ABC Inc.”. Would you expect to get back a fault named “DuplicateCompanyFault”, or would you expect to get back an error code, or something else? I guess the root of my question is would you prefer to receive faults to handle, error code, or some combination? These services are going to be consumed by multiple different entities outside our company on multiple non-.NET platforms. Any guidance here would be great.
Share
From an integrator’s standpoint I would prefer 1 fault type that represents an error from your API layer and inside that fault a codification of the reason for the fault and a textual description to provide additional information. Otherwise the error handling logic becomes overly complex.
In the case of your example say the fault code is 100 (which maps to the error Duplicate Company in yall’s spiffy API documentation) and the description in the message is “Could not add Company ABC Inc as it already exists”.