W3C home > Mailing lists > Public > www-qa-wg@w3.org > August 2004

[SpecGL] D5: Error handling

From: Dominique HazaŽl-Massieux <dom@w3.org>
Date: Tue, 03 Aug 2004 15:04:49 +0200
To: www-qa-wg@w3.org, david_marston@us.ibm.com
Message-Id: <1091538289.1416.199.camel@stratustier>
The last piece I had to produce, as far as I can tell.

David, I would like to mention something about the error handling in
XSLT 1.0, which I think you found ill-thought, due to the possibility of
having different behaviors for different errors; any pointer to a report
of interoperability issues that came out of this? or to more specific


Good practice: define an error handling mechanism

What does this mean:
For a language, address what effect an error (be it syntactic or
semantic) in the input has to a processor of this language.
For a protocol, address how should behave a party to this protocol when
a bogus message is received.

Why care?
There are many reasons a system may fail; to make a technology reliable,
it is crucial to define how it should react to bogus input.
Defining error handling also makes it possible for a user of the
technology to react appropriately to the error condition.

Different methodologies exist to handle errors in a technology:
- in a protocol, defining well-known error messages allows better
recovery and or reporting of these failures
- in a language, syntax errors (non-parsable content) and semantic
errors (meaningless content) can be handled separately or together; in
both cases, one should keep in mind that extensibility may need new
tokens (see WebArch document,
http://www.w3.org/TR/webarch/#extensibility), which can be smoothen by
the use of "mustIgnore" and "mustUnderstand" policies: in the first
case, a processor is required to ignore only the content that it cannot
understand, in the second one, it is required to consider as an error
that kind of content
- try and limit the number of types of error defined by the
specification; also, having errors of the same kind being processed the
same way allows greater interoperability

- the HTML 4.01 specification doesn't define an error handling policy,
although it encourages a "mustIgnore" policy
- the CSS specification relies on a well-defined "mustIgnore" policy
- the DOM uses well-defined exceptions and error values
- the XML specification is well-known for its strictness with error
conditions, where an ill-formed XML document must not be processed
- the HTTP specification defines a set of well-known error, standardized
through their error codes
- the XSLT 1.0 specification allows a processor to recover to some of
the defined errors, 
Dominique HazaŽl-Massieux - http://www.w3.org/People/Dom/

Received on Tuesday, 3 August 2004 09:05:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:33 UTC