OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: throwing SAX Exceptions from SAX Filters

"Michael Brennan" <Michael_Brennan@allegis.com>

> If this would only be used within the context of a SAX filter and nowhere
> else, I'd say just throw a SAXException. That's what I typically do.

Actually, I try to avoid throwing a SAXException of any kind directly.
I prefer to call the ErrorHandler and let that decide what to do.  It's not
always the case that you want to treat all errors as fatal.

In the example of this Fragmentations filter, wouldn't many users just want
to validate docs and report problems so they can be fixed in a batch?  Many
application level errors can reasonably be treated as validity errors, though
sometimes you might want to have more granularity than the three types of
error which ErrorHandler defines.

> SAXExceptions can conveniently carry another exception, so the application
> can determine what the real original exception was. I tend to leverage that
> pretty heavily. In fact, I always through a SAXParseException so that the
> application can get the Locator info and determine where in the XML source
> the error occurred. That's pretty useful for debugging.

Yep, I strongly encourage folk to use the Locator when reporting exceptions.
Essentially all significant SAX parsers provide one (though strictly speaking,
it's optional).  Good diagnostics are essential, and the SAXParseException
can be constructed with both the Locator and any "root cause" Exception.

If the SAX2 event handler is detecting a context-specific problem it really
ought to get associated with every problem report ... :)

- Dave