SAX: Error Reporting (question 4 of 10)

[David Megginson]

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.


CON
---

- 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.


PRO
---

- 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.


MY RECOMMENDATION
-----------------

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
XmlAppBase.


FURTHER CONSIDERATIONS
----------------------

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

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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