Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Error Reporting (question 4 of 10)
 James Clark wrote: > > > It seems very easy to map from a notWellFormed event to a notWellFormed > > exception and essentially impossible to map from the exception back into > > an event (with context etc.). > > Not at all. The exception can carry all the context that an event does > (like URL, line number and so on). I meant execution content -- the continuation. > You can't generate more than one fatal error event with this approach, > but that seems well out of the scope of a simple interface like SAX. I guess this is where we disagree. I don't see anything complicated about the event approach and see no reason to restrict people to catching a single well-formedness error. After all, we agree that there should be a callback for non-"fatal" errors, so adding another for "fatal" errors seems simpler to me than inventing an exception. > Apart from the fact that it is the right thing to do (show me a Java API > that uses a callback for a fatal error), The XML spec's definition of "fatal error" is quite different from common usage. In particular there is a lot of language about continuing after the fatal error. "The reports of the error's fatality are much exaggerated." What you are proposing strikes me as analogous to disallowing AWT window event handling after the window's "close" event. Sometimes there are good reasons for continuing... > there are two other reasons why > throwing an exception is the right approach: > > - Representing information about the error as an object allows much > better extensibility: implementations can extend > XmlNotWellFormedException to provide richer error reporting, and this > can be very conveniently exploited by applications. There are a dozen other places in SAX where this argument could be used. Most specifically: why should we have such precise, rich information about fatal errors and not about other errors? Wby not have an extensible Error interface that can be used in both callbacks. Before I am accused of starting down the slippery slope, I want to point out that errors are a special case in that the XML spec. does not specify a fixed, finite set of interesting information about them. > - A parser will read from a URL, thus it is already the case that it > will generate IOExceptions, and thus applications have to be prepared to > deal with this already. (I hope nobody is suggesting that the parser > should try to catch IOExceptions.) By deriving > XmlNotWellFormedException from IOException, an application doesn't have > to right any additional code to deal with fatal errors. True, but they must already handle non-fatal errors, so the extra effort in doing the same for fatal errors seems pretty small. Paul Prescod -- http://itrc.uwaterloo.ca/~papresco Art is always at peril in universities, where there are so many people, young and old, who love art less than argument, and dote upon a text that provides the nutritious pemmican on which scholars love to chew. -- Robertson Davies in "The Cunning Man" 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
|
|||||||||
