[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: throwing SAX Exceptions from SAX Filters
- From: Michael Brennan <Michael_Brennan@allegis.com>
- To: "'Simon St.Laurent'" <firstname.lastname@example.org>, email@example.com
- Date: Wed, 11 Jul 2001 14:20:13 -0700
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.
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.
> -----Original Message-----
> From: Simon St.Laurent [mailto:firstname.lastname@example.org]
> Sent: Wednesday, July 11, 2001 1:39 PM
> To: email@example.com
> Subject: throwing SAX Exceptions from SAX Filters
> I'm presently writing a SAX Filter which supports the Regular
> Fragmentations work I'm doing. As part of an effort to reduce the
> project's explicit reliance on the Xerces parser's regex routines (for
> matching) and the regexp's split() functionality, I'm building an
> interface which allows developers to create tiny wrappers around
> whatever regex package they find most appropriate.
> Part of that involves using the newInstance() method to create classes
> based on system properties or command line output, and I need
> to handle
> and throw exception. Although this code is part of a SAX filter, the
> work it is doing isn't explicitly SAX-related.
> Should I be throwing SAXExceptions? Or concocting something new?