Loading ...
Sorry, an error occurred while loading the content.

4221RPC Fault/Status/Error Codes & Exceptions

Expand Messages
  • mikeg@dulciana.com
    Jul 4, 2001
    • 0 Attachment

      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@...)