Correct way to handle errors in Web Service

[supermatchgame]

I am designing a 'connector' as an interface between the user and a database. The connector is a web service with a series of operations based on solicit / response.

Some of the operations return data in XML format - i.e. one of them can be passed a series of integers to produce reports from the database. The XML output will subscribe to a common schema.

I'm wondering how best to handle errors in my operations. These errors could either be user generated - they haven't sent a valid input parameter - or system generated (i.e. lost connection to database). I like the idea of being able to return a series of messages that tell the person who is consuming the web service exactly what is going on. But this message will be based on a different schema to the data that is returned.

So my question is: what's the best way to design this. Should I expect that the consumer will be OK with potentially receiving two different message types depending on how the operation went? Should I build the message into an attribute of the data schema so I can just return an empty XML document with a header attribute set to 'Error - invalid input parameter' or something like that. Or should I just force the consumer to handle a SOAP error message and not give them any help? After all if I have documented the operations and clearly stated that 9 is not a valid input then it's not my fault, right?

Does anyone with industry experience have any insights? I'd be really grateful for some input because I'm tying myself in knots here.

 

[jmeckley]

another option is to create a more robust schema. something like

errors
error
error
data
xml they probally want.


if no errors occur the errors node contains no error nodes. the data would contain the xml they want. if an error does occur create an error node under errors for each error. the data node would be empty.

whom ever consumes the server can then preform a simple check. if errors.count > 0 display error messages, else process xml data.

since this is a service and generally considered the end of a context so, you should not send across system errors (database, io, null reference, etc). these should be logged and then send a user defined exception to the client with a general "an error occurred". validation should be sent as this will inform the user of their entry errors.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[supermatchgame]

Great, thanks for this. I asked a consultant on site what he thought and he pretty much said what you did word for word. I have added an error element to each schema with a message sub-node to store the custom error message. That way if the error information needs expanding at any point I can easily add in more sub nodes to allow this. Any developer consuming the connector can test for the existence of the error node as a first port of call, i.e.

If (errornode.Exists()) == true
{
  //display error message
}
Else
{
  //display data returned by web service
}

I also hear what you're saying about not returning the system generated error message (no one likes to see the errors that the .NET Framework throws up ) but throwing it into an ErrorLog table and just returning a generic 'sorry, an error occurred' message.