Is it Ok to throw exceptions back to a client from my service?

Question

I am writing a Java based service with WSDL for a .Net client to consume, and I thought that when I receive an invalid value from the client that I would throw an exception that my client could then catch and display in a message box or something to the user (the client is a desktop app).

I was wondering if it would be ok to use this approach or if there's a better way of doing it.

Answer 1

I would say "no". Error messages, etc., but I wouldn't serialize an exception. You have no idea who the client is or what language they're written in.

The service should handle the exception: catch it, log it, and create a sensible error message(s) and status codes. This is not the place for exceptions, in my opinion.

And when I say "sensible error messages", I don't mean anything resembling a stack trace. These are likely to be business clients, who should not be reading such things. A business-meaningful message is the ticket here, not a stack trace.

Answer 2

.NET in general deals in FaultExceptions (wrapped SOAP faults) in WCF. I would assume that if you throw a proper SOAP Fault, that WCF would wrap this up into a FaultException by the time the client consumes the response, so they can have a try catch FaultException statement. This would still allow other non .NET clients to consume the service without breaking standards..

Just an idea anyway...

Answer 3

What you should probably do is use SOAP Faults, since these should be supported for any clients. Be sure to set the extra descriptive fields too.