> -----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 --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 the suggested 'ValidateException', or maybe something like 'FOParseException'. 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 :-) ) > Java gives us a large family of predefined exceptions > for use in our coding--I'm leery of proclamations of > them being No Good and that each and every Java > application must re-invent their own exceptions > instead. That just seems sloppy. > Exceptions are very OK indeed, but I think that merely using the prefined ones is, in a way, missing the point. They were designed to be 'thrown' around as well as 'extended'. One can act as a sort of collector for all other types, centralizing error-handling and providing a tidy stack trace, with immediate indicators as to where the problem poses itself --in terms of location in the process as well as a possible location in a file... 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'? What about: - LayoutException - AreaException - RenderException ... +1 for Finn's suggestion. Cheers, Andreas
