SAX: Error Reporting (question 4 of 10)

[Paul Prescod]

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 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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)