CODEWITHSUNDEEP
web-servicessoapexceptionasmx
Ryan Tomlinson
Ryan Tomlinson

Reputation: 884

Should web services throw exceptions OR result objects

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.

Upvotes: 12

Views: 13418

Answers (7)

K W
K W

Reputation: 1

If the web service will be consumed publicly, cyber-security red teams will love verbose error messages that allow interrogation of the infrastructure. Then we can target that server with specific exploits.(This is not a good thing). Your code will pop up in the issues register. The people suggesting using any default .NET exception messages in a public web service are just suggesting variations on a theme or disabling your diagnostic capability. Custom exception text that doesn't divulge how to attack the server is recommended.

Upvotes: 0

James Hall
James Hall

Reputation: 6689

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.

Upvotes: 0

azheglov
azheglov

Reputation: 5523

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.

Upvotes: 2

Maladon
Maladon

Reputation: 298

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.

Upvotes: 8

Bogdan_Ch
Bogdan_Ch

Reputation: 3336

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.

Upvotes: 0

Bruce
Bruce

Reputation: 8430

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?

Upvotes: 0

John Saunders
John Saunders

Reputation: 161783

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.

Upvotes: 7

Related Questions