Saxon

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

You seem to be using your own code for displaying the exception. Have you looked inside it to see if there is any location information? Potentially it holds a lot of context information. There are some static methods in the standard ErrorListener that you could try to invoke (or adapt). Sometimes, though, the location information doesn't make it through, especially with Validation errors. You can switch on the equivalent of the -T option by registering an XSLTTraceListener with the Controller.addTraceListener() method. As a short-cut, see how the command line interface net.sf.saxon.Transform does it. Michael Kay

Legacy ID: #3246959 Legacy Poster: W. Eliot Kimber (drmacro)

You're right, I'm just catching Throwable and printing the stack trace--didn't realize that was my code. I'll see what I can get from the exception. Cheers, Eliot

Legacy ID: #3247027 Legacy Poster: W. Eliot Kimber (drmacro)

OK, now I have code like this: try { transformer.transform(new StreamSource(inputDoc), new StreamResult(outputFile)); } catch (ValidationException e) { System.err.println(" - ERROR: Saxon Validation Exception: " + e.getMessage()); System.err.println(" - Line: " + e.getLineNumber() + ", column: " + e.getColumnNumber()); System.err.println(" - Location: " + e.getLocationAsString()); System.err.println(" - File: " + e.getSystemId()); But now I can't recreate the validation exception (I had fixed the data problem that was triggering the failure and can't seem to recreate the conditions that were causing it). Doh! Is there an easy way to cause a validation exception? Everything I tried gets caught by the type checking, which results in Saxon-emitted messages with context information. Or maybe my question should be: why do validation exceptions not result in messages the way type checking does? Thanks, Eliot

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

The easiest way to force a validation exception is to do something that can't possibly be detected at compile time, e.g. <xsl:param name="x" select="'20Z'"/> <e xsl:validation="strict"> <xsl:attribute name="should-be-int" select="$x"/> </e> However, Saxon is doing its best to give location information for validation errors, and hopefully only a few of them slip through the net. Are you running with the "validation warnings" option which causes validation failures on a final result tree to be non-fatal?

Legacy ID: #3248140 Legacy Poster: W. Eliot Kimber (drmacro)

I think I may have misunderstood the immediate cause of the failure. I assumed the validation was of the XSLT instance (but handled as a run-time error). But of course this must be validation of the generated instance. Hmm. That explains why I couldn't reproduce the failure just using XSLT stuff. I hadn't noticed the validation warning option, but in this case, I'm generating XSLT as output and I would want any datatype mismatch to terminate the process since the resulting XSLT would fail with a type check (but then that might make it easier to debug the issue since I could trace the generated XSLT code back to its source in the XSLT generator--hmm). I'll keep digging. Cheers, Eliot

Legacy ID: #3248162 Legacy Poster: W. Eliot Kimber (drmacro)

I see why I missed VALIDATION_WARNINGS: it's not mentioned in the Invoking XSLT from Java page, although it is, of course, listed in the javadocs. Cheers, E.

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

A Validation Error might mean a schema validation error on the input file, in which case the location information should relate to the position in the input file, or it might be a schema validation on an output tree (either a temporary tree or a final output tree) in which case the location information should be the position in the stylesheet that wrote the bad output. I introduced the VALIDATION_WARNINGS option because I found I sometimes wanted to write stylesheets that get the broad structure of the output right before worrying about the fine detail; also it means you can catch several errors in a single run. Michael Kay