Re: [xsl] saxon:try()

Subject: Re: [xsl] saxon:try()
From: Florent Georges <lists@xxxxxxxxxxxx>
Date: Mon, 7 Jan 2008 22:32:56 +0100 (CET)
Colin Paul Adams wrote:

> It confuses me because now I don't know which handler will
> be invoked for a particular error.

> E.g. If within an ex:try block, I call unparsed-text
> ('file://non-existent-file'), and also reference a global
> variable, which makes the same bad call to
> ('file://non-existent-file') within it's own ex:try block,
> which handler gets invoked?

> Worse, suppose the call in the global variable doesn't
> have a try block? Now do I catch the error or do I creash?

  This is a good question.  There are two problems here: has
the error raised from the variable value computation to be
caught, and which error will be caught if the try sequence
constructor contains two errors?  Let me give two examples
for those.

    <xsl:variable name="v" select="error()"/>

    <xsl:template match="/">
             <xsl:sequence select="$v"/>
          <ex:catch>Error occured!</ex:catch>

  Here, the transformation must fail, because the variable
declaration is not in the try.  This doesn't prevent the
processor to do lazy evaluation, but it must then retain the
try dynamic context of the variable declaration for when it
will actually evaluate the variable value.

  If you want to prevent the global variable evaluation to
throw an error, use something like this:

    <xsl:variable name="v" as="node()"/>
             <xsl:sequence select="error()"/>
             <xsl:sequence select="'alternative value'"/>

  Second example, when the try sequence ctor could throw two

    <xsl:template match="/">
             <xsl:sequence select="error(QName('my:ERR001'), '')"/>
             <xsl:sequence select="error(QName('my:ERR002'), '')"/>
             Error: <xsl:value-of select="ex:current-error()"/>

  Here, I think we should let some freedom to the processor
as the order of evaluation is not defined, and say that one
of the error must be caught, but which one is undefined.

> I can only predict this if I know the processor internals
> (i.e. when the variable actually gets evaluated).

  I think this is taking the problem backward: we should
instead define what an implementation must conform to, and
then processors should implement that.  It can remain some
implementation-defined or undefined things (a specification
should take into account existing implementation techniques
as well I think), but this is the job of the processor to
implement what has been defined.

  Of course, that would have an impact on optimization
opportunities...  But that wouldn't avoid them.

  Of the top of my head, Michael provided five interresting
use cases with such special cases related to the ways Saxon
can rewrite the expressions.  That was on the Saxon Help
mailing list, but the SF list archive is not searchable for
now (there is a problem there), so I can't post the link

  Thank you for your feedback.



Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

Current Thread