Return to Question

So 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

Edit: Clarification: 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: Coz it would make server side code a lot more uniform
2. Why are we thinking error codes: Coz 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. I just want to know if the community feels that's the case here

Edit2: Also would the answer change if we were talking to Managed clients instead of Native clients

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?

So 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

Edit: Clarification: 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: Coz it would make server side code a lot more uniform
2. Why are we thinking error codes: Coz 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. I just want to know if the community feels that's the case here

So 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

Edit: Clarification: 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: Coz it would make server side code a lot more uniform
2. Why are we thinking error codes: Coz 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. I just want to know if the community feels that's the case here

Edit2: Also would the answer change if we were talking to Managed clients instead of Native clients

So 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

So 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

Edit: Clarification: 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: Coz it would make server side code a lot more uniform
2. Why are we thinking error codes: Coz 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. I just want to know if the community feels that's the case here