Should web services throw exceptions OR result objects.

Question

I'm not sure I'm completely happy that throwing exceptions in web services is a good idea. I wouldnt mind as much if it wasn't for the stack trace. This is not something I wan't.

I have researched around several implementations and there really doesn't seem to be a consensus on this. CampaignMonitor for example does return a Result object, yet others don't.

Architecturally, I'm not sure returning a return object makes sense, surely an exception is an exception, but what I do like about a Return object is that it is a more graceful solution for the end user.

Does anyone have any better solutions?

EDIT

BTW I am using ASMX web services, where turning CustomErrors on is not an option.

Answer 1

What stack trace are you talking about? Have you tried this?

In both ASMX and WCF services, an uncaught exception will be translated into a SOAP Fault. In both cases, they can be configured to not include any stack trace. In fact, that's the default in WCF.

So, the proper way to return an error like this is through a fault. One way to generate faults is to throw and not handle an exception.

Answer 2

Can you clarify a bit? The server-side of a web service can throw an exception. The server-side of a web service can return a message to the client-side. That message may contain error information, and that error information may specifically include exception details. Or it may not. On the client-side, you typically have a generated proxy to deal with the message from the server. This proxy may generate an exception if that response contains error information.

Which part of this scenario are you wondering about?

Answer 3

I suppose that throwing exceptions is in general a better design pattern then returning a result. I suppose that you have to do is inside your web services to hide stack trace by applying the following pattern to each method exposed as web service:

public void MyWebServiceMethod() {
try
{

 ///Do something that may cause an error

} catch(Exception ex)
{ throw new ApplicationException("User friendly descritption of exception");

}

}

or you may also

catch(Exception ex) { throw ex; }

If you re-throw an exception, you will hide original stack trace from the clients of your web services.

Answer 4

Don't let the fact that you're in a web service confuse the issue. That's just an implementation detail.

Use your normal exception handling strategy. Best practice says don't trap exceptions in low level code -- unless you can resolve that exception there and continue normally. Exceptions should be raised to the presentation layer so the user can be informed of the error.

So, as applied to web services -- in general throw exceptions (which results in a SoapFault). This allows the invoking client code to use it's built-in exception handling standard to handle it.

Answer 5

one approach is to separate system and business errors. (System error: e.g. malformed request, user-not-authorized, etc.; business error: e.g. method UpdateCars results in an error, the user doesn't own any cars).

In case of a business error, return a response object containing an error description; in case of a system error, throw an exception.

Answer 6

I dont see why you can't do both? Catch the exception, log it (either to a DB or to a file), then return an error code. That way you have a graceful execution of the webservice call, and also notification of the error, and you have a spot elsewhere you can further debug.