Search the web
Sign In
New User? Sign Up
xml-rpc · XML-RPC Discussion
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Want your group to be featured on the Yahoo! Groups website? Add a group photo to Flickr.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
Error reporting other than a fault   Message List  
Reply | Forward Message #6745 of 6839 |
Re: [xml-rpc] Error reporting other than a fault

>So, I'm returning an error but it's not an XML-RPC fault.

Yes. It's not only better than extending XML-RPC, it's the right
architecture anyway. Errors should be layered.

And you can be lazy and still provide adequate diagnostic information
to the human user if you get past the idea that errors should be
described by machine-understandable codes. In most cases, a program
looks only at whether a function succeeded or failed, and passes any
other error information on to a human. So, at each layer, have a
binary success indication and a detailed text message. As a failure
percolates up the stack, each layer adds its text explanation to
additional text explaining the context in which it failed, so that the
ultimate message that gets to the human user is a complete
explanation, without the code having to parse anything or be modified
each time a new failure mode is added to another layer.

That way, when the login fails, the response is a simple fault
response with a fault string that says, "Login failed because 1)
userid 'joe' doesn't exist and 2) password has invalid format - is
less than 8 characters." Because there's a fault, the program simply
abandons what it was doing and displays the fault string for the user.

In fact, ideally the "call" function in the client XML-RPC library
returns its own failures with text messages, and the caller doesn't
even have to distinguish between a failure at the server and a network
problem that prevents sending the RPC at all. In both cases, the
program sees a generic failure and displays an explanatory error
message.

Because some clients can make use programmatically of a breakdown of
error information (including at what layer the failure happened),
while others are just going to report to a human, I like to see
options (perhaps different methods/functions) for the client to
indicate what kinds of errors he can deal with.

E.g. the client program might be able to respond to a "file not found"
condition by trying an alternate file. In that case, the client
should call the "read this file or tell me there isn't one" method
instead of the "read this file" method, and if the file doesn't exist,
the RPC _succeeds_ with information in its result saying it
successfully determined that the file doesn't exist.

--
Bryan Henderson San Jose, California



Wed May 21, 2008 4:51 pm

giraffedata
Offline Offline
Send Email Send Email

Forward
Message #6745 of 6839 |
Expand Messages Author Sort by Date

I'm curious how to handle more complex error situations than the XML-RPC fault will support. Should I just create and document additional response payload...
Bill Moseley
whmoseley
Offline Send Email
May 21, 2008
2:43 pm

... That seems exactly the right thing to do. Please resist trying to "extend" or "improve" the basic XML-RPC protocol. This just limits the usability of your...
John Wilson
tug123uk
Offline Send Email
May 21, 2008
2:49 pm

... Yes. It's not only better than extending XML-RPC, it's the right architecture anyway. Errors should be layered. And you can be lazy and still provide...
bryanh@...
giraffedata
Offline Send Email
May 21, 2008
6:20 pm

... Bryan, Both you and John responded about avoiding extending the XML-RPC spec. I hope I was clear, I'm not suggesting that. For example, I was not ...
Bill Moseley
whmoseley
Offline Send Email
May 21, 2008
7:16 pm

... 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...
bryanh@...
giraffedata
Offline Send Email
May 22, 2008
2:32 am

... 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 ...
Bill Moseley
whmoseley
Offline Send Email
May 22, 2008
5:34 am
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help