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: 
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.
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.