I am more in agreement with your patch.  +0 as-is.

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [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

(According to the recent W3C email [3] though, we will
never have a DTD or other type of schema to validate
XSL with.) 




> > 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

(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

> 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.)


Reply via email to