Exceptions or Error codes

Question

We are building a web service(SOAP, .Net) which would be talking to (mostly) native clients (windows, C++) and we are wondering what is the best way to communicate errors to the client (e.g. SomethingBadHappened like login service not available or something like user not found) and haven't been able to decide between throwing exception to the client or using some kind of error code model to do the above.

What you would prefer on the handling on the client side: receiving a error code or handling a ServerFault exception which contains the reason for the error?
1) Why are we thinking exception: Because it would make server side code a lot more uniform
2) Why are we thinking error codes: Because we think it makes more sense from the client side perspective.

If 2) is really true we would probably want to go for error codes than exceptions? Is that the case here?

Also, would the answer change if we were talking to managed clients instead of native clients?

Answer 1

SOAP has a concept of faults, you can convert an exception to a fault on the server side and on the client proxy the fault can again be converted back to an exception. This works remarkably well in WCF and Java metro stack, cannot comment on native C++ clients.

As regards to SOA best practice define one generic fault and few specific faults only if the client need to handle a certain type of error differently. Never send a exception stack trace to client in production deployment. This is because in theory the server trace has no meaning for the client and for security reasons as well. Log the full error and stacktrace on the server and send a unique reference to the log in the fault. In WCF I use the Microsoft Exception Handling block from Enterprise Library to generate a guid and also convert a exception to SOAP fault.

Check the guidance at Microsoft Patterns and Practices.

Answer 2

I recently did a web service with the Java 6 libraries, which can report an exception back to the caller (I haven't looked into how as it is done automatically).

The ability to have the client provide a stack trace in the error report to the developer has been very useful (opposed to getting an approximate timestamp and then have to look it up in your logs, if you happen to log it).

So, seen from a developers point of view, use Exceptions.

Answer 3

If it's a web service, you can't exactly cause the server to throw an exception that will be caught by the client. At the interface, your server basically has to return some sort of error code, even if that's a string that says An exception occurred. Type %s, message %s, stack trace %s.

As for the client side, you could have your response reading code check the response to see if it contains an error and raise an exception on the client side. That's a very good way to do it, in languages with good exception handling at least. C++, though, does not have good exception handing, and it's a good idea to stay as far away from C++ exceptions as possible. If you can't use a better language, then just stick to error codes.