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@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)