C
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
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