Architecture question: Exceptions vs status codes

[chen]

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:
try {
response = proxy.GetFoo();
switch ( response.StatusCode )
{
case Success:
// response.Foo is valid
case NotFound: // handle this error
case OtherError:
// look at response.ErrDetail for additional
context about the error
....
}
}
catch (SoapException ex)
{
// unpack the Detail element to figure out what happened &
handle it
// appropriately
}
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?
TIA

[Michael Höhne]

I would never use status codes if exceptions are possible - and I say that
cause I'm working with a system that's not capable of generating SOAP fault
messages that can be interpreted by the client in a meaningful way and so I
have to use status codes there!.

If status codes are valueable for your solution, you still have the option
to include them in the SoapException and parse it at the client to throw new
exceptions that can be handled smoothly. It may not be elegant, but the code
will be much more readable and whenever you forget to catch an exception you
will note it (assuming there's not final catch {} clause).

While I'm convinced that exceptions are the better solution, I'm sure to see
other posts that will tell the opposite, because both approaches are valid.

Michael
"chen" <ve******@sig.com> schrieb im Newsbeitrag
news:11*********************@g47g2000cwa.googlegro ups.com...

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:
try {
response = proxy.GetFoo();
switch ( response.StatusCode )
{
case Success:
// response.Foo is valid
case NotFound: // handle this error
case OtherError:
// look at response.ErrDetail for additional
context about the error
....
}
}
catch (SoapException ex)
{
// unpack the Detail element to figure out what happened &
handle it
// appropriately
}
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?
TIA