Hello Andreas! (and others) --- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote:
> > -----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. [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. 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.) <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.) 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 } 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. Thanks, Glen
