4221RPC Fault/Status/Error Codes & Exceptions
- Jul 4, 2001Hi,
I've got a design question about the handling of fault, status or
error codes and exceptions within RPC function signatures in SOAP.
And this forum appears to offer the best mix of users, implementers
and XMLP contributors that may be able to give a useful opinion!
Function signatures, whether RPC or not, typically need some way of
signalling error conditions. In the old days, typically we used to
return an integer value where zero indicated success and non-zero
values indicated specific error conditions. Modern languages have
introduced the concept of exceptions which simplifies programming by
allowing the error conditions to be handled "out of band".
But the general principle is still largely the same in both cases.
That is, provide an indication of the success or failure or the
function, and if failure provide a specific (and perhaps application
dependent) error code indicating the nature of the error condition.
So the question is how best to represent this in SOAP?
There appear to be three options:
1) Follow the SOAP 1.1 specification and use "Fault" mechanism,
extending the "faultcode" element to indicate application specific
error conditions. The "faultstring" element can be used to provide
supporting information for human consumption.
2) Return a SOAP 1.1 "Fault", but put the application specific
error information in the "detail" element. For example, this could be
extended with new "errorcode" and "errormessage" elements.
3) Explicitly model "errorcode" and "errormessage" elements in the
SOAP response message.
Option (1) appears to be the cleanest design and most closely follows
the suggestions in the SOAP 1.1 specification. If you follow those
suggestions, however, it does involve the creation of lots of
application specific QNames in the SOAP "envelope" namespace. For
example, you might invent "Client.MyParameterMissing" and so on. Is
this a problem?
Would it be preferable to use an application specific namespace
for "faultcode" values?
In either case, does this risk breaking client software that may just
check for "VersionMismatch", "MustUnderstand", "Client" and "Server"?
I see examples of all three approaches on the Internet. For example,
Microsoft .NET appears to use option (2). But this seems clumsy and
rather heavyweight and it ignores standard SOAP features.
Option (3) is easy to implement but very inelegant and it pollutes
the RPC function signature with unnecessary parameters. Plus it makes
error handling convoluted as you need to check multiple error codes.
What do the "SOAP Builders" think is the best approach? Which has the
most tool support (some SOAP toolkits don't allow you presently to
modify the SOAP "faultcode" element at all)? What is the likely
direction for XMLP?
Thanks & Regards,
-Mike Glendinning (mikeg@...)