[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Error Reporting (question 4 of 10)
David Megginson <ak117@f...> wrote [09:50 AM 1/3/98 ]: >Should SAX treat errors as events? If so, should it distinguish fatal >errors from warnings or non-fatal errors? Yes. Yes. Details below for those who care... >There is an important distinction here: warnings are strictly >informative, and may be useful for debugging, [clip] >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: [clip] >Normally, these would throw an error or exception, and the programmer >might want to display the message in a dialog box. We should not make decisions a priori for Clients. Which messages the Client might or might not want to show to users (or otherwise act on), should not be pre-determined in the interface. >CON >- Java already has throwable errors and exceptions, which provide a > more elegant method for error reporting. But, as far as I know, there are no (good?) cross-language exceptions handling mechanisms. How would a C++ or PERL client catch a Java exception? >PRO >- some OO languages do not have throwable errors and exceptions; this > approach should be simple enough to work with all of them; Right. >- there can be default implementations in XmlAppBase, so users can > ignore these if they wish. As mentioned in the thread "do we want a base class," I propose that we not assume the presence of an XmlAppBase beast when formulating the PRO/CON lists. >MY RECOMMENDATION >----------------- > >Yes to both. > >We can have the following default implementations in XmlAppBase: [clip] Good for Clients, not for Implementors, for reasons stated previously. >FURTHER CONSIDERATIONS >---------------------- [clip] >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). I'd really like to see the column information. I'd also like to have an offset from the start of the stream. Somebody (Tim? James?) said that their parser did all three. I've often needed all of them. This one isn't a killer, though, and your defined behavior for non implementors is a fair tradeoff. David ================================ David Ornstein Pragmatica, Inc. http://www.pragmaticainc.com 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
|