SAX: Error Reporting (question 4 of 10)

Matthew Gertner matthewg at
Mon Jan 5 11:05:20 GMT 1998

>Tim Bray writes:
> > On this one, I agree with David and disagree with James.  I don't
> > see the advantages to using an exception.  I think that a SAX processor
> > should use fatal() (why the longer fatalError()?) - this has the
> > advantage that you can, after the first message, go on looking for
> > more fatal errors.  Of course, a SAX processor must not, after the first
> > fatal() callback, emit any more element() or charData() callbacks.
>The only problem here is that the element context could be useful for
>error reporting (i.e. "Error in <name> in <address> in
><frontmatter>").  When XML documents are machine generated, this type
>of an error message might be more useful than a line number.

Obviously the consumer could be made responsible for maintaining an element
and/or entity stack (cf. Jame's early message on this topic) without putting
additional onus on the parser to hold this information. On the other hand,
it might be worth considering using an XMLLocation class or suchlike to hold
the line number and offset information for the calls which require this
information, rather than passing them as separate parameters. This would
enable "consenting" producer/consumer pairs to use a derived class (e.g.
XMLFatalErrorLocation) containing additional information provided by the
parser. It would also enable future extensions without changing the

Matthew Gertner
Project Manager/Architect, Internet/Document Management
POET Software GmbH
Tel: +49 (40) 609 90254
Fax: +49 (40) 609 90115
E-mail: matthewg at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list