Project

Profile

Help

Bug #2713

closed

NPE from XQuery when catching collection URI resolver exception

Added by Gunther Rademacher about 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Category:
XPath conformance
Sprint/Milestone:
Start date:
2016-04-15
Due date:
% Done:

100%

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

Description

A test of ours contained some code that used fn:collection with a relative URI inside of try-catch. This now results in a NullPointerException.

I understand that a relative URI now requires a base URI to be set, but apparently the corresponding error message fails to pass through catch processing.

This can be reproduced from command line by

java net.sf.saxon.Query -qs:"try {collection('x/y?select=z.xml')} catch err:FODC0002 {'caught'}"

java.lang.NullPointerException

    at net.sf.saxon.pattern.NameTest.matches(NameTest.java:207)

    at net.sf.saxon.expr.TryCatch.iterate(TryCatch.java:255)

    at net.sf.saxon.expr.Expression.process(Expression.java:887)

    at net.sf.saxon.query.XQueryExpression.run(XQueryExpression.java:408)

    at net.sf.saxon.s9api.XQueryEvaluator.run(XQueryEvaluator.java:370)

    at net.sf.saxon.Query.runQuery(Query.java:900)

    at net.sf.saxon.Query.doQuery(Query.java:442)

    at net.sf.saxon.Query.main(Query.java:111)

Files

NPEfromCatch.java (1.12 KB) NPEfromCatch.java Gunther Rademacher, 2016-04-15 15:19
Actions #1

Updated by Gunther Rademacher about 8 years ago

Some further testing showed that I am getting the same exception and stack when throwing an XPathException from a CollectionFinder, e.g.

		configuration.setCollectionFinder(new CollectionFinder() {			
			@Override
			public ResourceCollection findCollection(XPathContext paramXPathContext, String paramString) throws XPathException {
				throw new XPathException("Class " + getClass().getName() + " refused to find collection " + paramString);
			}
		});

The test program is attached. Now working around by throwing a RuntimeException.

Actions #2

Updated by Gunther Rademacher about 8 years ago

...but did not realize until now that this is a Saxon XPathExcetion. Using its setErrorCode method helps as well.

Actions #3

Updated by O'Neil Delpratt about 8 years ago

  • Category set to XPath conformance
  • Status changed from New to Resolved
  • Assignee set to O'Neil Delpratt
  • Priority changed from Low to Normal
  • % Done changed from 0 to 100
  • Fix Committed on Branch 9.7 added

Thanks for reporting the problem you found. The exception thrown did not have a error set upon creation, which is a bug. I have added the correct error code 'FODC0002' as expected.

Bug fixed and committed to subversion on the 9.7 and the development branch.

Actions #4

Updated by O'Neil Delpratt about 8 years ago

In addition to the above fix we have taken the step to check if the code is null, which if it is we then assign it a default saxon error code. This precaution was added in the TryCatch class.

Actions #5

Updated by O'Neil Delpratt almost 8 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.7.0.5 added

Bug fix applied in the Saxon 9.7.0.5 maintenance release.

Actions #6

Updated by O'Neil Delpratt almost 8 years ago

  • Sprint/Milestone set to 9.7.0.5

Please register to edit this issue

Also available in: Atom PDF