> -----Original Message-----
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
<snip />
> 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.
>
True, but I still think it's a bit forced to have lines like the following
in FOP's source code:
throw new SAXParseException(...);
Especially if they appear 'out of nowhere' --the difference between
'catching and re-throwing the SPE' and 'just throwing an SPE because that
exception class happens to provide us with a Locator'.
You might want to try searching Xalan source code BTW: I don't think Xalan's
actually throwing them anywhere, it merely *uses* them in the sense of
'catch and possibly throw a TransformerException' or define a method with
'throws SAXParseException' because the method in question contains
instructions that might throw one.
The 'clean' way IMHO would look sth like:
try {
// instructions that might throw SPE
} catch( SAXParseException spe ) {
// obtain info from spe + provide possible logging msg
// and if really fatal to the app...
throw new FOPException( spe, [other args?] )
}
<snip />
>
>
> This way, user's embedded code would be (pseudocode):
>
> try {
> driver.run();
> } catch (SAXParseException) {
> // tell user there's a bug in the stylesheet
> } catch (FileNotFoundException) {
> // tell user a file can't be found
> } catch (Exceptiion) {
> // anything else
> }
This embedded usage argument seems a bit out of place... IMHO, embedded
users shouldn't even *have* to make the distinction between SPE or FNFE
themselves --they should just be able to catch a FOPException, which would
in turn give them access to all they need to know.
So, where you say: 'catch an FNFE and tell the user a file can't be found',
I think it would be better if FOP just sent the message 'that a file was not
found', and the embedded user just needs to get this message from
FOPException and send it to a logger of his/her choice or deal with the
error as he/she pleases, but he/she certainly shouldn't have to deal with
SPE's or FNFE's directly.
> > [Me: ]
> > What about:
> > - LayoutException
> > - AreaException
> > - RenderException
> > ...
> >
>
> This would fail, because there's no way to
> identify/group errors based on the failing of the
> user. i.e., a FNF exception can occur in any of those
> three areas, depending on how we implemented the code.
That is the point exactly: by merely using the predefined FNFE, you wouldn't
be making a distinction at all as to where or why the error occurs.
It's a matter of *what* classes *can* throw these types of exceptions, and
that would be defined/outlined in FOP's API. --As opposed to the predefined
exceptions, which can be thrown virtually anywhere... i.e. a FNFE can be
thrown in any class that attempts to create a reference to a File.
LayoutExceptions, for instance, would only be thrown by classes in the
fop.layout or fop.layoutmgr packages.
If you pass the originally caught exception (whatever the type) as parameter
to FOP's own exceptions --in essence: wrapping it--, 'instanceof' can then
be used to determine whether the cause was a FileNotFoundException /
NullPointerException / ArrayIndexOutOfBoundsException. If a FNFE is
encountered somewhere in FOP, and it is ultimately passed on to FOPException
(via AreaException or LayoutException), additional info can be added along
the way, info that can be highly context-dependent.
Furthermore, there may be errors that aren't rooted in any of the predefined
exception classes, but for which we still might want to throw an
exception --although I must admit that ATM I'm having trouble imagining one.
Of course, in the latter case we could limit ourselves to just throwing
'naked' Exceptions (without giving any indication whatsoever about what went
wrong).
Cheers,
Andreas
