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

The first thing to tackle is preventing against exceptions being thrown by doing validation on data before it gets manipulated. IE

string func(string cat)
if(cat == null || cat.length == 0){
//set errorLabelText to "bad data"
return;
}
//else code

That being said only throw Exceptions in Exceptional cases.

Answer 3

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

Conceptually this is fine, but I don't think you can literally throw a Java Exception over HTTP back to a .NET client.

You can use HTTP 500 to signal a server error; you should also be able to attach a meaningful message to the response that will help the .NET developers figure out how to use your service better. This may or may not include a serialized Java stack trace.

Answer 5

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.