Re: Action item on the virtues of error-handling

This feels off the mark a bit, to me...

On Tue, 2003-10-21 at 22:11, Tim Bray wrote:
> One of the characteristics that distinguished the Web from preceding 
> hypertext systems is that the protocols defined behavior in the 
> presence of errors.  For example, HTTP defines a standard response with 
> an error code (404) for a common case of a failure to access a resource 
> via its URI.  Also, HTML specifies "must-ignore" processor for 
> user-agents that encounter markup that is not part of HTML.

Actually, it doesn't. The spec acknowledges that some software
does this, but doesn't mandate it in any way.

>   Another 
> example is XML, which has a rigorous definition ("well-formedness") of 
> what constitutes an XML document and how software should react when 
> encountering data that fails to meet that definition.

I think that was a necessary evil; a reactionary response
to the HTML bugward-compatibility nightmare.

Having HTTP recognize that the Web is a distributed system by
including fault codes in the protocol feels very different, to
me, from having the XML spec constrain behaviour of what to do with
things that are not XML documents.

> Web Architecture requires designers of protocols and software to 
> specify error-handling behavior.

I don't agree.

The Web is a distributed system, so Web Architecture requires
that designers of protocols not constrain components in different
parts of the network to stay in sync.

I'm not sure what the central principle is, but I can't sign
up to the one you suggest.

>   There is no architectural preference 
> for any particular error-handling behavior;

Well, we are agreed that silent recovery from error is harmful,
because agents that do that are not faithfully representing
their users.

I think Web Architecture has a preference for error behaviour
that encourages folks to Do The Right Thing... a 404 error
message is useful because it can say "contact the author of
the _referring page_" and such. XML halt-and-catch-fire
was useful/necessary to make broken XML docs sufficiently painful
to consumers that they'd contact the producer and get it
fixed rather than just tolerating it.


>  for example both HTML's 
> must-ignore policy and XML's well-formedness policy have been highly 
> successful.

I don't think "HTML's must-ignore has been highly successful" is
self-evident; it has serious drawbacks.

Here's hoping I find time to elaborate...

> Cheers, Tim Bray  http://www.tbray.org/ongoing/
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 21 October 2003 23:01:25 UTC