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?

Just to add a bit of clarification: a) I am looking for best practices here and experience from the client side (since the client is lot more complicated and we would rather handle stuff at server side if we can keep client code simpler) b) The client contains a lot of legacy code and we may or may not be able to use C++ exceptions.
–
Amit WadhwaNov 1 '10 at 6:30

This may help- www.codeproject.com/KB/cpp/cppexceptionsproetcontra.aspx
–
GulshanSep 16 '13 at 8:06

3 Answers
3

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.

Thanks this sounds good. Can you give me a more specific link there within the page there.
–
Amit WadhwaNov 1 '10 at 18:07

Also what about business level errors like UserNotFound etc. should these also be handled as exceptions
–
Amit WadhwaNov 1 '10 at 18:16

It past projects we never used Exceptions in code or Faults in SOAP to communicate legitimate/expected modes of failure. We used error codes and left them up to the client to decide what to do with them. User not found is not really an error/exception, this should probably be a status code.
–
MrLaneMay 26 '14 at 3:44

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

I agree that this could be useful in dogfood and beta, but do you really want to spew out stack traces in event logs or log files in real world usage (and of course revealing more details about the service than you need/want to in process)
–
Amit WadhwaNov 1 '10 at 6:45

2

@Amit, trust me on this: If you hit a situation giving a stack trace in production, you WANT the stack trace!
–
user1249Nov 1 '10 at 7:50

1

What's the benefit on stack trace on the client side, We will definitely log all exceptions on server side before passing it on to the client.
–
Amit WadhwaNov 1 '10 at 18:05

Also what about business level errors like UserNotFound etc. should these also be handled as exceptions
–
Amit WadhwaNov 1 '10 at 18:16

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.

I guess the uncaught exception would go as ServerFault to the client
–
Amit WadhwaNov 1 '10 at 5:11

3

There is nothing wrong with C++, or C++ exceptions. There are plenty of reasons to use a language other than C++ for certain projects, but exception handling is not one of them.
–
KeithBNov 1 '10 at 14:07

Not only that it is against security best practices: What exactly should the client do with the stack trace of your server? Print it and send it to you? Send as email? Use for lube paper?
–
JensGDec 9 '13 at 18:04

@JensG: If this is a web service and not a website, the client should be professional enough to email it to you as a bug report.
–
Mason WheelerDec 9 '13 at 18:07