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/>



Reply via email to