Finn, I am more in agreement with your patch. +0 as-is.
--- Finn Bock <[EMAIL PROTECTED]> wrote: [Finn] > > [Glen] > > > SPE might be considered the XML parsing > > equivalent of a "syntax error" that would occur > for a > > code compilation error. > > Right, errors at the XML level. > It *can* be used for validation too. As shown here [1], If FOP had a DTD that we validated against using a validating parser, validation errors would also raise a SAXParseException [2]. The folks at Sun did not see a need for another type of exception to raise for validation errors (as opposed to pure parse errors), at least for validations done by the parser itself. (According to the recent W3C email [3] though, we will never have a DTD or other type of schema to validate XSL with.) [1] http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXPSAX13.html [2] http://java.sun.com/webservices/docs/1.0/tutorial/examples/jaxp/sax/samples/Echo10-06.html [3] http://lists.w3.org/Archives/Public/xsl-editors/2004OctDec/0016.html > > As the definition of its parent SAXException[1] > > states, "This class can contain basic error or > warning > > information from either the XML parser *or the > > application*" So it can be used within FOP. > > Indeed, and that is exactly what my proposal does: > > """ > If the application needs to pass through other types > of exceptions, it > must wrap those exceptions in a SAXException or *an > exception derived > from a SAXException*. > """ > 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. (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.) > > FNFE is the right choice to throw when a file is > missing. > SAXParseException the the right choice when a file > contains invalid XML. > ValidateException is the right choice of exception > when the FO file > doesn't follow the content model. Different cases > that require different > exceptions. > Agreed. I now understand the difference between XML parsing errors and validation errors, I didn't so clearly yesterday. > > I don't think any FNFE are thrown very far in FOP, > but it should be > wrapped in a FOPException (or in a > ResourceMissingException?) and passed > back, at least to the LM level, perhaps further. > If convenient internally (so our methods do not have to declare several different exceptions that can be thrown), then OK. FOPException can be abused because the programmer is not really thinking about what the precise error is, just that it occurred within FOP. (If the embedded user cares if the FNFEx. was within FOP, he/she can get this knowledge by strategic use of try/catch blocks anyway.) Thanks, Glen
