Project

Profile

Help

Bug #4364

closed

Better handling for UncheckedXPathException

Added by Radu Coravu almost 3 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2019-10-29
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Platforms:

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..
Actions #1

Updated by Michael Kay almost 3 years ago

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.

Actions #2

Updated by Radu Coravu almost 3 years ago

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.

Actions #3

Updated by Michael Kay almost 3 years ago

  • 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 UncheckedXPathException and handle it in the same way as a checked XPathException.

No custom tests - relying on regression testing.

Actions #4

Updated by Michael Kay almost 3 years ago

  • Status changed from New to Resolved
Actions #5

Updated by Radu Coravu almost 3 years ago

Great, thank you,

Actions #6

Updated by O'Neil Delpratt over 2 years ago

  • 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.

Actions #7

Updated by Archie Cobbs over 1 year ago

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:?]

Actions #8

Updated by Michael Kay over 1 year ago

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