SAX: Error Reporting (question 4 of 10)
ak117 at freenet.carleton.ca
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 freenet.carleton.ca
Microstar Software Ltd. dmeggins at microstar.com
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev