Re: Error reporting other than a fault

>I believe your responses were that adding a higher-level error system
>into the payload is the way to go.

Well no, it depends on just what your goal is, but if it's what I think
it is, I would go with a fault, because it's a whole lot easier for your
users to use.

But I wouldn't encode error information into the fault string (I think
that's what you mean by "serialize").  I'd put it in English.  That's
because I think the only use the client will make of your list of
failures is to show it, ultimately, to a human for diagnosis.
Likewise, I wouldn't pay any mind to the fault code.

But if I'm mistaken and there's some way the client will respond
automatically depending on the nature of the failure, _then_ I would
go with putting the information in a method response instead of
failing the RPC (returning a fault).


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.

A compiler is a counterexample, but I'm pretty sure that's only
because they used to run in batch jobs and submitting a job for each
error was just too expensive.

-- 
Bryan Henderson                                   San Jose, California

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

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/