Project

Profile

Help

Bug #4301

Incorrect namespace URI in error code produced using fn:error()

Added by Jiri Dolejsi over 2 years ago. Updated about 2 years ago.

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

100%

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

Description

I do not know, if it is a bug or my misunderstanding.

using System;
using Saxon.Api;
using System.IO;
using System.Text;
using System.Collections.Generic;

namespace TestSaxon
{
    class Program
    {
        static Processor processor = new Processor(true);
        static String s = @"<xsl:transform version='3.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:xs='http://www.w3.org/2001/XMLSchema'>" +
       @" <xsl:template name='xsl:initial-template' as='xs:string'> " +
       @"    <xsl:param name='code' as='xs:string'/> " +
       @"    <xsl:sequence select=""if ($code = ('test')) then $code else error(QName('http://www.ctk.cz/error-code/', 'NotExists'))""/> " +
       @" </xsl:template>" +
       @" </xsl:transform>";

        static void Main()
        {
           try
           {
                XsltCompiler comp = processor.NewXsltCompiler();
                Xslt30Transformer transformer = comp.Compile(new StringReader(s)).Load30();
                var p = new Dictionary<QName, XdmValue>();
                p.Add(new QName("code"), new XdmAtomicValue("abc"));
                transformer.SetInitialTemplateParameters(p, false);
                XdmDestination dest = new XdmDestination();
                transformer.CallTemplate(null, dest);
            }
            catch (Saxon.Api.DynamicError err)
            {

                if (err.ErrorCode.Uri == "http://www.ctk.cz/error-code/")
                {
                    return;
                }
                else
                    throw;
             
            }
        }

    }

}

I expect exception with my custom namespace, but Saxon throws exception, which says, that it can not serialize result

When I omit as attribute inside or use as='item()*' then it works.

I am using Saxon EE, 9.1.1.4, .NET Framework 4.7

History

#1 Updated by Michael Kay over 2 years ago

  • Description updated (diff)
  • Assignee set to Michael Kay

#2 Updated by Michael Kay over 2 years ago

  • Assignee changed from Michael Kay to O'Neil Delpratt

#3 Updated by Michael Kay over 2 years ago

  • Subject changed from Is custom exception convertible into any type ? to Incorrect namespace URI in error code produced using fn:error()
  • Category set to Diagnostics
  • Status changed from New to In Progress
  • Assignee changed from O'Neil Delpratt to Michael Kay

I've reproduced this (in a new Java JUnit test TestXslt30Transformer/test4301).

As a consequence of the as="xs:string" on the named template, the call on error is wrapped in an Atomizer (effectively data(error(....))). The Atomizer catches the exception thrown by the call on error() and adds diagnostic information ("... Failed while atomizing...."). In this course of this it loses the namespace URI of the error code.

#4 Updated by Michael Kay over 2 years ago

  • Status changed from In Progress to Resolved
  • Applies to branch trunk added
  • Fix Committed on Branch 9.9, trunk added

I've patched this so that Atomizer no longer changes the error code or error message if the error code is in a non-standard namespace.

This isn't really a 100% solution; ideally the error message should be preserved intact for any call on error(), regardless of namespace. This would mean using a subtype of XPathException for the exception thrown by fn:error(), and recognizing that specially. I've implemented this solution for the next major release.

#5 Updated by Jiri Dolejsi over 2 years ago

I have one question: Is it possible to obtain patched version of Saxon or must we wait for official release on saxonica.com/Download ?

#6 Updated by Michael Kay over 2 years ago

You'll have to wait until the next maintenance release, I'm afraid. Generally we do local testing of patches before we commit them, and a limited set of regression tests as a nightly routine, but we don't run the full test suite until it's time to build a new release.

The next maintenance release should be fairly soon as we've built up a sufficient number of patches to justify it, however, we've got a bit of a backlog of bugs to fix from the holiday period and we'll try to make inroads into that first.

#7 Updated by O'Neil Delpratt about 2 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.5 added

Bug fix applied in the Saxon 9.9.1.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF