Cart
[Home] [By Thread] [By Date] [Recent Entries]
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:simonstl@s...] > Sent: Wednesday, July 11, 2001 1:39 PM > To: xml-dev@l... > 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?
|
