Saxon

Legacy ID: #4188216 Legacy Poster: Michael Kay (mhkay)

With your own ErrorListener, you can suppress the display of error messages, and you can cause warnings to be ignored (because the only thing that happens on a warning is to display an error message). You can also influence the handling of those errors that the XSLT specification describes as "recoverable errors". But you can't turn fatal errors into non-fatal errors. The message "Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor" is a warning so it's easy enough to suppress that. But an error like passing a date as the argument to xs:double() is fatal, and the only thing you can do in your ErrorListener is to change the way in which it is reported. >If I set the error listener then not matter whether I throw back the error in MyErrorListener or not I get only a TransformerConfigurationException in the catch block of loadStyleSheet That's correct. If you want to make more information available, your ErrorListener should place it somewhere where the enclosing application can find it. This technique is used in the Saxon API on .NET, where the error listener simply adds all the error messages to a list, and the calling application can process the list in any way that it likes, for example it can provide a user interface that allows the user to scroll backwards and forwards.

Legacy ID: #4188332 Legacy Poster: Stefan (snenkov)

Hi Michael. Thank you this is very helpful. If I collect all the errors from MyErrorListener (warnings, errors, fatal errors) in one Vector can I later differentiate whether they are warnings, errors, fatal errors or need to put them in separate vectors? What does the method XPathException.isTypeError() do? Stefan

Legacy ID: #4188393 Legacy Poster: Michael Kay (mhkay)

The Exception object itself doesn't know whether it was notified as a warning, an error, or a fatalError: you'll have to remember that yourself somehow (I would wrap the exception and the category in another object). isTypeError() isn't really used much. Because the spec distinguishes type errors from other dynamic errors, I tried to do the same in the implementation, but there's no real difference in behaviour. Except possibly that type errors occuring during compile time are reported immediately, whereas non-type-errors are deferred until run-time.