Saxon

Looking at the specification of XMLReader.parse(), it is just amazingly bad:

Throws: SAXException - Any SAX exception, possibly wrapping another exception. IOException - An IO exception from the parser, possibly from a byte stream or character stream supplied by the application.

No indication at all as to whether or not it's expected to throw a SAXException in the event that an invalidity was found.

My immediate concern however is that we don't appear to be calling the supplied ErrorHandler for each validity error.

Indeed, although the application calls ValidatorHandler.setErrorHandler(eh), the validity messages are being sent to an InvalidityHandler that wraps the standard ErrorReporter rather than the user-supplied ErrorHandler.

Getting this right is proving troublesome. Schema.newValidatorHandler() constructs a pipeline to perform the full validation, and a subsequent call on setErrorHandler() (or setResourceResolver()) needs to dive deeply into this pipeline to change some of its properties. This is clearly under-tested.

The InvalidityHandler is a property of the ValidationContext object. The simplest solution seems to be to add the ValidationContext as a property of the PipelineConfiguration, allowing ValidationHandler.setErrorHandler() to access it and set its InvalidityHandler.

Now returning to the question of parse() throwing an exception at the end. This comes from ValidatingFilter.reportIfInvalid(), which tests the property getPipelineConfiguration().isRecoverFromValidationErrors(). The least disruptive solution seems to be for SchemaReference.newValidatorHandler() to set this property.

I have added a set of unit tests for the JAXP ValidatorHandler.