Finn Bock wrote:
[Peter]
On the topic of exceptions, and now that it's all over...
I was puzzled by this discussion. Would anyone expect that Defoe
would subclass SAXException for document validation errors?
That is your choice. Surely exceptions that occured during SAX event
handling (eg startElement) should be handled, either by wrapping the
exception in a SAXException, or by passing SAXExeption subclasses along
or by throwing some kind of RuntimeException (did I miss another
option?). I don't think exception handling by
e.printStackTrace();
is a long term solution.
If not (it doesn't), why not?
Certainly. SAX errors would be.
AFAIK, there is no well defined API to XSL:FO parsing, so everybody will
do it differently.
And if someone was inclined to write an FO processor using a DOM
front-end, would you expect validation errors to throw subclasses of
SAXException?
Ofcourse not.
The same fo file, with the same errors, could be processed by three
different processors, using three different parsing methodologies, and
the same validation errors would encountered.
Do you mean that the 3 different processors should ideally report the
same validation errors in the same manner? That can only happen after
someone standardize a SAFO API (Simple API for FO parsing). Until then
all implementation will throw different exceptions, which is fine by me.
No, just trying to illustrate the independence of the function of
validation from parser methodology.
(OK, you can classify at least two categories of validation error, but
I think the argument still applies.)
SAX != XML parsing, let alone document validation.
True, but FOP heavily depends on SAX.
My point was that there is no necessary connection between parser
methodology and "application-level" validation. In the abstract, such
validation occurs independently of parser methodology.
Peter
--
Peter B. West <http://cv.pbw.id.au/>
