Re: Error reporting other than a fault

On Thu, May 22, 2008 at 02:10:26AM +0000, [email protected] wrote:
> 
> In my servers, I return this sort of thing as a fault until I know a
> specific case where the client needs to distinguish different kinds of
> failure programmatically.  Then I make a new version of the method
> that provides those details in the result.  That minimizes wasted
> effort both by me and by my users.
> 
> On another subtopic: it's really unusual for any procedure call,
> remote or otherwise, to return multiple failures, and I can't recall
> ever wishing for one to do so.  Usually, it stops at the first failure
> detected and returns that.  The user fixes that problem and
> iteratively works his way through the other failures.

Here's an example:

The application is agnostic as to how it's used (could be via the web,
a cron job, command line interface, or XML-RPC).  One of the
operations the application can handle is a method to add a record to
the database about a job applicant.

Let's take the web interface.  Say we have a form to enter data about a
job applicant.  So there might be a web form with fields for name,
address, phone, and maybe a select list for a department and one for a
job id.

When that form is submitted there may be one or more validation
errors -- phone may be blank and the department number is not valid.

In a web form it is common for the form to be redisplayed with an
error saying the form needed fixing and then next to the phone and
department fields specific error messages ("phone number is required",
"department id is invalid").

It would be very frustrating to have a web form that only told you one
problem at a time (phone is required), then you fix and resubmit only
to find another field needs fixing.  Just not acceptable.

Now, we want to expose this same method to enter data about a job
applicant via the web service.  Clients using the service might
be submitting applicants in a batch, or maybe there's some interactive
service they are providing.  What they are doing is not important,
just as long as they provide the required data in the request.

So, imagine a user of the web service wants to create their own web
form on their web site to submit job applications via XML-RPC to our
application.  They would also want to list all the problems with the
form submission after a single request.  Therefore, the need to return
multiple error messages associated with each input parameter.

So, yes, there's a fault condition that the request failed (due to
validation errors) but there's the need to provide detailed
information about that failure.

I can't return an XML-RPC fault AND provide detailed information, so
instead I'm returning a status and list of errors in the payload.



-- 
Bill Moseley
[email protected]


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/