I see. Thanks for the explanation. Glen
--- Finn Bock <[EMAIL PROTECTED]> wrote: > [Glen] > > > I'm not clear why you didn't derive > > ValidationException from SAXParseException. I > know > > the locator is already present in FOPException, > but > > absent the subclass from SAXParseException, it > ends up > > being a "different" Locator object, i.e., user > code > > that would handle a SAXParseException can't handle > > this FOPException. Perhaps just a nitpick, but I > see > > a long-term advantage in having our > > ValidationExceptions subclass SAXParseException if > > possible. > > Sometime when a PropertyException is thrown (f.ex > during evaludation of > a relative numeric) the name of the property and the > location is not > available. In the patch I've added a catch in > PropertyParser which add > the property name and location information to the > PropertyException and > rethrows the augmented exception. SAXParseException > keeps the location > information private so it is not possible to change > the location info > after a SAXParseException is thrown. Other than > that, the hierarchy > could also have been rooted in SAXParseException. > > > (Namely, if an embedded user of FOP wished to > report > > both parsing and validation errors to the user in > the > > same manner--a plausible scenario--it would be > > convenient to have ValidationException subclass > > SAXParseException.) > > ValidationException and SAXParseException both have > SAXException as a > parent, so a user can catch SAXException to deal > with the different > exception in a uniform manner. > > regards, > finn >
