SAX: Error Reporting (question 4 of 10)

David Megginson ak117 at
Sat Jan 3 17:55:28 GMT 1998

Should SAX treat errors as events?  If so, should it distinguish fatal
errors from warnings or non-fatal errors?

  public void warning (String message, String systemID, int line);
  public void fatalError (String message, String systemID, int line);

There is an important distinction here: warnings are strictly
informative, and may be useful for debugging, i.e.

  WARNING: assuming UTF-8 encoding.

Normally, these would go to STDERR or to a log, and people would view
them only if they were trying to track down a problem.  Fatal errors,
on the other hand, should ordinarily stop processing and fling
themselves in the user's face:

  FATAL ERROR: tag mismatch: end tag "foo" for element "bar"

Normally, these would throw an error or exception, and the programmer
might want to display the message in a dialog box.


- these methods will make SAX slightly larger;

- there is no XML requirement to report non-fatal errors at all;

- Java already has throwable errors and exceptions, which provide a
  more elegant method for error reporting.


- some OO languages do not have throwable errors and exceptions; this
  approach should be simple enough to work with all of them;

- exceptions are not always a good idea, since it might not be
  possible to restart the parser when one is caught;

- it is useful to be able to warn the user about possible problems
  without causing a fatal error (hence the warning method);

- there can be default implementations in XmlAppBase, so users can
  ignore these if they wish.


Yes to both.

We can have the following default implementations in XmlAppBase:

  public void warning (String message, String systemID, int line)
    System.err.println("WARNING (" + systemID + ',' + line + "): " + message);

  public void fatalError (String message, String systemID, int line)
    throw new Error (systemID + ',' + line + ": " + message);

These would be appropriate for most simple applications, but could
easily be overridden for more complicated ones derived form


If we decide to implement startEntity() and endEntity(), then the
systemID argument to these methods will be redundant (the current URI
will always be known); in that case, should we still leave the
systemID argument in for convenience?

Do we need a 'column' argument as well as a 'line' argument, or is
'line' enough?  I don't know if all parsers track the current column,
but we could define a behaviour for those that do not (such as
reporting the column as -1).

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