[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SAX: Error Reporting (question 4 of 10)
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@f... Microstar Software Ltd. dmeggins@m... http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|