Bug #4364
closed
Better handling for UncheckedXPathException
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Description
In the DITA Open Toolkit there is some Java code running a transform with Saxon 9.9 over an XSLT stylesheet and it breaks with an UncheckedXPathException, the entire stack trace is logged here:
https://github.com/dita-ot/dita-ot/issues/3395
A couple of things which seem not quite right to me:
- I do not expect the "TransformerImpl.transform" method to throw RuntimeExceptions, the jaxp interface does not state that it could do that. In my opinion on the method "net.sf.saxon.jaxp.TransformerImpl.transform()" the exception should be caught, unwrapped and the XPathException inside it thrown again.
- The UncheckedXPathException once created should at least inherit the stack trace, system ID and line/column information from the embedded XPathException, otherwise when it is logged in the console I have no idea in which stylesheet the problem was..
Yes, you're right we should catch this and convert it back to a standard XPathException. It's less clear what we should do with other unchecked exceptions thrown by an ErrorListener (or other callback). We're moving slowly to support the JAXP ErrorListener only as a legacy interface: it's replacement will not throw checked exceptions, and will be a functional interface with only one method.
Great, thank you. Just for completion, the problem in the XSLT was thrown in the context of:
<xsl:variable name="map" select="(*[contains(@class,' map/map ')])[1]"/>
<xsl:element name="{name($map)}">
where the $map variable did not evaluate to anything useful, so the name of the element remained empty.
- Category set to Diagnostics
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.9, trunk added
- Fix Committed on Branch 9.9, trunk added
I have added code to the main entry points for XSLT and XQuery compilation and evaluation to catch an UncheckedXPathExceptio
n and handle it in the same way as a checked XPathException
.
No custom tests - relying on regression testing.
- Status changed from New to Resolved
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.9.1.6 added
Patch committed to the Saxon 9.9.1.6 maintenance release.
Is this bug supposed to be fixed in Saxon HE 9.9.1.8?
I'm still getting an unchecked exception leaking through Transformer.transform()
:
net.sf.saxon.trans.UncheckedXPathException: Processing terminated by xsl:message at line 25 in foobar.xsl
at net.sf.saxon.lib.DelegatingErrorListener.fatalError(DelegatingErrorListener.java:51) ~[saxon-he-9.9.1.8-saxon-he.jar:?]
at net.sf.saxon.Controller.reportFatalError(Controller.java:467) ~[saxon-he-9.9.1.8-saxon-he.jar:?]
at net.sf.saxon.trans.XsltController.applyTemplates(XsltController.java:758) ~[saxon-he-9.9.1.8-saxon-he.jar:?]
at net.sf.saxon.s9api.AbstractXsltTransformer.applyTemplatesToSource(AbstractXsltTransformer.java:347) ~[saxon-he-9.9.1.8-saxon-he.jar:?]
at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:349) ~[saxon-he-9.9.1.8-saxon-he.jar:?]
at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:71) ~[saxon-he-9.9.1.8-saxon-he.jar:?]
This will be a different bug with the same symptoms. Please raise it as a new issue, with a test case that we can reproduce.
We use unchecked exceptions on paths where Java doesn't allow checked exceptions, which sadly are becoming increasingly common if you want to use new features like streams and lambdas. The idea is that we catch the unchecked exception and convert it back before returning to the user, but it's in the nature of unchecked exceptions that it's difficult to test your code to make sure all paths are covered (despite the conventional wisdom, I think checked exceptions are an excellent language feature that help to produce robust code).
To find the particular path by which this unchecked exception is escaping, we need to reproduce it.
Please register to edit this issue
Also available in: Atom
PDF