Hello Andreas! (and others)

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>

> > -----Original Message-----
> > From: Glen Mazza [mailto:[EMAIL PROTECTED]
> >
> >
> Hi Glen,
> > I'm confused--why is OK to throw SAXExceptions but
> not
> > its child SAXParseExceptions?  With the latter, it
> > just holds locator information necessary to
> pinpoint
> > the problem for the user.  Please elaborate.
> >
> It seems more about not throwing SAXParseExceptions,
> but catching them and
> throwing a FOPException instead. Isn't that the
> issue? That a
> 'missingChildElementError' is actually not a
> SAXParseException... because it
> has nothing to do with SAX in itself 

SAXParseExceptions would appear to be for errors that
occur during the SAX parsing of an XML document (as a
result of a user supplying an invalid XML document). 
It is not for errors that occur within the
implementation of the SAX processor (e.g., Xalan)
itself.  SPE might be considered the XML parsing
equivalent of a "syntax error" that would occur for a
code compilation error.  

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.


--it's a
> violation of a definition as
> formulated in the XSL-FO Rec. The error is treated
> and reported as being a
> SAXParseException only because the latter offers the
> convenience of a
> locator, but it should actually be something like

No, because the SAXParseException is for such
validation errors, regardless of what you're parsing. 
Learn once, use everywhere:  Batik, FOP, Cocoon, Axis,
etc., etc.  (Also, as a minor additional benefit, it
helps pluggability if all XSL processors adopted
SAXParseException instead of each of us coming up with
our own name for this.)

> the suggested
> 'ValidateException', or maybe something like
> 'FOParseException'.

Using that logic, a SAXParseException would never be
used anywhere, because it is SAX usually used to
validate the XML document.  If it's no good for FOP,
then it would be no good for Batik, and Cocoon, and
Axis, and then we're back to rarely using Java
exceptions directly in one's coding. 
SAXParseException is there for a purpose:  to be used,
it's already coded and documented!

> Throwing a SAXParseException actually seems more
> confusing to the end-user
> (--he/she who, on average, reads little more than
> the first two lines of the
> stack trace :-) )

Maybe not, because a SAXParseException has the benefit
of the user knowing it already (and if they don't know
it, they will learn it *now*, and get to apply this
knowledge for future parsing of other languages.) 
Also, our SAXParseExceptions each have detailed error
messages telling them what the problem is.  (The stack
trace they usually won't see anyway, unless they
choose to run in debug mode.)


> What's wrong with an app having its own set of
> particular exceptions
> reflecting its overall design, according to 'what
> can go wrong and where'?

Excellent question.  The reason is that exceptions are
for the benefit of the user using the software, and
he/she has usually no internal knowledge of the
software product itself.  The user doesn't know about
FO trees, area trees, layout, renderers--this is all
our language that is collectively a black box to the
user.  Furthermore, users don't care *where* the error
occurred inside the black box (advanced users have the
stack trace anyway), they do want to know *what* went
wrong though, so they can group those *what's*
together and report on them in a common manner.

For example, I see two main errors that can occur with

1.) syntax error:  elements not following (a) proper
ordering or (b) invalid values for properties.  These
should raise a SAXParseException, with IMHO not
*necessarily* a need to differentiate between the two
because they both imply the same problem:  badly
written stylesheet, as well as the same solution:
fix/redo your stylesheet.

2.) file not found errors.  Here, the stylesheet is
fine, but it can't find the various .gif's or other
hardcoded filenames within it.  These should raise a
FileNotFoundException, to indicate to the user they
need to relocate files.  (I'd like Finn BTW to
elaborate why he feels FNFE would not be a good idea 
for FOP, I don't see the problem with it.)

There may be minor ones besides these, that most
external users can trap with a regular Exception at
the end.

This way, user's embedded code would be (pseudocode):

try {
} 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

> 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.
 How will they create a common error message for a FNF
error if we group as above?  Or a common error to
indicate they need to rewrite their stylesheet? 
Ultimately, a user cares about the type of their
error, not so much where it occurred in our product.

Sorry for the long post.  Comments welcome.


Reply via email to