Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi, Tim -- > I'm writing some java code that uses a basic SAX parser, and I haven't > done this for years if ever, and the callback routines all have > signatures that throw SAXExceptions, [...] 1) For what you describe, subclassing on SAXException or on SAXParseException (which already extends SAXException) is the way to go. Choose SAXParseException if you want to include locator information in a format that a downstream client will know how to access. In the code that calls xmlreader.parse(), you can use a catch MySAXExceptionSubclass to see if the exception was one of yours. 2) You could also equip your handler with an ErrorHandler and report through that interface as opposed to throwing exceptions, allowing the ErrorHandler implementation to throw an exception when appropriate (e.g., on a "fatal" error). (Subclassing on SAXParseException can be useful here, but the assumption would be that the ErrorHandler implementation wouldn't necessarily be yours.) #2 makes more sense for validation or informational use cases. My $0.02. -- Paul
|
