RE: Action item on the virtues of error-handling

FWIW:  my intuition is that one may want somewhat different error handling 
philosphies for protocols that present information to a user than for 
those that are strictly machine-to-machine.  Within limits, users are 
capable of exercising a sort of open-ended judgement that software 
applications typically don't.  I am not making the simplistic assumption 
that therefore forgiving protocols such as HTML are necessarily 
appropriate to interactive applications, or that one should never use the 
"if you don't understand it skip it" model for machine-2-machine.  I'm 
just suggesting that the presence of a human is a factor to consider, and 
that perhaps that thought might (or might not) add some nuance to a TAG 
error handling finding. 

I think one needs to be particularly careful with protocols that are used 
in both contexts, as both SOAP and REST models do with HTTP.  I was 
reminded of this by the recent uproar over the Verisign site-finder 
service, which effectively turned a 404 into an HTML page with information 
about alternate web sites.  Well, whatever you think about SF's other 
merits (and I don't think we should open that debate here), I'd argue that 
the relatively informal response they give is at best useful to a human 
reader, but completely inappropriate to either a SOAP application, or some 
other application doing a GET for machine-readable information.   So, I 
think that's an example that highlights how one can be tempted to use 
error handling strategies or guidelines in one context that don't work in 
the other, particularly in siutations where the same protocol is used for 
both interactive and machine-to-machine purposes.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Received on Friday, 24 October 2003 16:35:21 UTC