Architecture question: Exceptions vs status codes

We're having an internal debate about the merits & demerits of
returning status codes in the output message vs exceptions to signify
errors in handling a Web method.

The status code camp is arguing that business rules related errors are
to be conveyed using status code while reserving the exception approach
(using SoapException) to system related errors (like say database
connection issues). This implies that GetFoo() returns a composite
message that includes StatusCode, Foo (the result) as well as other
error code/descriptions.

The cons of the status code approach is that it makes client side code
really painful:

The other big drawback, is that the client could completely ignore the
status code. Also, the status codes will have to be conveyed
"out-of-band" thru other means of documentation - the .wsdl alone is
perhaps not sufficient.

The exception camp is arguing for using Soap Faults in the WSDL &
throwing SoapExceptions from the web method. This allows for
consistent handling of all errors (business or system related errors)
on the client side.

The cons of the exception approach is that 1.1 WSDL simply ignores the
SOAP Fault when generating client side proxy code. [Other toolkits,
notably, Axis for e.g. turns the SOAP Faults into custom exceptions
which makes it easier for clients to handle them appropriately].
Does WSDL 2.0 and/or WCF (Indigo) handle SOAP Faults any better?

Although the exception approach seems like a hands down winner, are
there any scenarios where returning status code might make sense?? or
is exception approach the way to go always? Comments?

Advertisements

In my experience dealing with application related errors, it's always best
to "throw" those to the client and let client handle them, this way there's
no ambiguity to the client, itâ€™s an exception that have to be handled;
display message to the users, log it, ignore it, whatever.
Besides any client should have try catch around web service call anyway to
check for other errors like Internet connectivity.
> catch (SoapException ex)
> {
> // unpack the Detail element to figure out what happened &
> handle it
> // appropriately
> }

There is not really any unpacking to do: ex..Message and ex.InnerException
should be sufficient to tell you what went wrong for most of the cases. Also,
from what I understand, when Web Service throws an exception .NET runtime
does generate SOAP Fault message as part of the response, and proxy class
built with VS .NET should pick it up and load it into Exception object for
you.

As far as custom error messages/codes, I am not a big fan of magic numbers.
It requires too much administration, documentation and creates unnecessary
confusion.

Advertisements

I also think if there is no much concerns about using custom exceptions in
your scenario, it'll be the prefered means. And for status code, it's good
and simple if we're designing a certain well-defined and reusable
framework( e.g the COM runtime system....). Otherwise, for concrete
business logic specific application, we're recommended to define some
custom exceptions(with human readable error message....) and put the
exception handling code at clientside.....

Please feel free to post here if you have any other concerns or
consideration...

Right now, it appears that the Soap faults are merely documenting the
fact that GetFoo() operation could result in NotFound fault code. All
the tools that i tried (WSDL, wseWSDL) ignore them & there doesn't
appear to be any easy way to turn them into custom exceptions on the
client side. So does it add any value in specifying them in the .wsdl
at all? What are some of the best practices in this area?

yes, for ASP.NET Webservice, it has limited exception framework, the
serverside webservice can only propagate SoapException as the exception
object to clientside.... And our serverside custom exception detailes can
be encapsulated in the SoapException's properties.... (xmlNode....). The
msdn .NET exception management guide also mentioned this:

I'm more towards using a different approach: return an enum
1. a switch statement to check the returned value, or a set of catch ( ...)
blocks is pretty much the same; you have to define the returned/thrown items
and handle them anyways
2. re "client could completely ignore the status code": you could to that
with an exception, but not trapping or using catch ( Exception ex )
3. security issues: the information from an exception could expose to a
hacker the structure of your application/webservice
4. the client side proxy code could reflect changes in the values of the
enum; if you change the exceptions thrown by the service, or add new ones,
you gotta make sure you convey that to all your clients cuz no proxy code
generator will do that for you
5. marshalling an exception across application domains is very expensive,
and will make your application less scalable (it's several orders of
magnitude slower than a return value)

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!