[Andreas]
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
[Glen]
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.
You mean xerces, right?
Xerces throws SAXParseException for all kinds of invalid XML:
<root> <block> </root>
org.xml.sax.SAXParseException: The element type "block" must be terminated by the matching end-tag "</block>".
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.
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*.
"""
[1] http://xml.apache.org/xalan-j/apidocs/org/xml/sax/SAXException.html
--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.
Thoughful people can disagree about that.
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.)
Heh. It appears that Batik have choosen to root their hierarchy in RuntimeException and Cocoon in avalon. I don't know about Axis. I'm sure both project has valid reason for their decisions, but it is a pipedream to think all projects would ever use the same.
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.
It is thrown by xerces. And caught by all users of all SAX parsers.
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.
Invalid argument. It incorrect to make conclusions based on this single case. And the other project have already chosen differently.
>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.)
If that is your argument, then we *certainly* shouldn't throw SAXParseException, since users know that a SAXParseException means that the XML input can't even be parsed, and much less transformed. When they see a SAXParseException they would begin by looking at the input XML, not on the output XML from the transformation.
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.)
Good, so does ValidateException.
<snip/>
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 FOP:
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.)
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.
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 { driver.run(); } catch (SAXParseException) { // tell user there's a bug in the stylesheet
Here you can't tell if the error was in the input XML (like a missing end tag) or in the generated FO stream. My proposal allows user code to tell the two cases apart.
} 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?
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.
regards, finn
