Bug #2713

NPE from XQuery when catching collection URI resolver exception

Added by Gunther Rademacher over 4 years ago. Updated over 4 years ago.

XPath conformance
Start date:
Due date:
% Done:


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


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'}"


    at net.sf.saxon.pattern.NameTest.matches(

    at net.sf.saxon.expr.TryCatch.iterate(

    at net.sf.saxon.expr.Expression.process(



    at net.sf.saxon.Query.runQuery(

    at net.sf.saxon.Query.doQuery(

    at net.sf.saxon.Query.main( (1.12 KB) Gunther Rademacher, 2016-04-15 15:19


#1 Updated by Gunther Rademacher over 4 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() {			
			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.

#2 Updated by Gunther Rademacher over 4 years ago

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

#3 Updated by O'Neil Delpratt over 4 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.

#4 Updated by O'Neil Delpratt over 4 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.

#5 Updated by O'Neil Delpratt over 4 years ago

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

Bug fix applied in the Saxon maintenance release.

#6 Updated by O'Neil Delpratt over 4 years ago

  • Sprint/Milestone set to

Please register to edit this issue

Also available in: Atom PDF