SAX: Error Reporting (question 4 of 10)

David Megginson ak117 at
Sun Jan 4 01:11:04 GMT 1998

James Clark writes:

 > There are 3 things that need to be distinguished:
 > - Fatal errors: violations of well-formedness constraints; processors
 > have to detect these and must stop normal processing.  In Java I think
 > an exception is the only reasonable way to handle these.  Unless you do
 > this people will be tempted to continue processing in violation of the
 > spec.
 > - Errors: violations of validity constraints or other errors that a
 > processor is not required to detect.
 > - Warnings: messages about conditions that do not cause a document to be
 > non-conforming.

Perhaps, then, we should have three callbacks.  I don't agree that we
should automatically use exceptions for fatal errors, because
sometimes it will be useful to try to report more than one error at
once -- the Java XmlAppBase class will throw an Error by default for
fatalError, however.

 > To do a really good job of reporting these, much more information is
 > needed that a line number and a URL.  In particular you need more
 > information about the entity structure.


 > I can guarantee you are not going to be able to do a good job of error
 > reporting and still keep the interface simple.

Agreed: good error reporting is out of scope.  If the startEntity and
endEntity events survive in SAX, then at least some information on the
entity structure will be available; furthermore, individual
implementations can stuff extra contextual information into the
'message' argument if they wish.

In the end, we are not looking to provide the kind of detailed error
reporting that NSGMLS does -- SAX is a production interface, not an
authoring one, and needs only give a very rough indication of why it
is giving up.  Normally, then, the author should turn to a validating
parser for full debugging support.

All the best,


David Megginson                 ak117 at
Microstar Software Ltd.         dmeggins 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