Best practices for error handling in a web service

Question

I'm now toying around with WebServices, using the .NET framework (.asmx files, not WCF). I'm wondering what's the best practice to tell the user that some sort of business-error has happened in the method call.

My small test-case:

I have measuring probes which need to register with a central server. Each probe should have a different physical address. To register, they should call (via a web service):

[WebMethod]
public void RegisterReadingStation(out Guid sessionId, Int64 physicalAddress)

Now, the signature is not set in stone - actually, that's what I'm trying to figure out. :) I need to somehow alert the probe if it's trying to register itself using a physical address that's already taken.

The way I see it, I got a few possibilities:

• Throw a SoapException containing the information. However, a string::message isn't really that easy to do programmatic checks on.
• Use some sort of value-class as a return parameter (or even simpler, an enum). If I do this, I guess I had to manually serialize / deserialize the class on the server/client?

Any thoughts about this?

Answer 1

I return a small class called ResultSet from each WebMethod, which contains an int errorcode and a string errormessage.

This gives you an easy check for error/success, and some details if things go wrong.

If the WebMethod needs to return data, I'll inherit from ResultSet to give a specific ResultSet to include the data as well.

Answer 2

I think the common concensus would be use a custom return code (integer). As long as the service documents what the possible return codes are, this should be feasible.