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="/"> <ex:error-safe> <ex:try> <xsl:sequence select="$v"/> </ex:try> <ex:catch>Error occured!</ex:catch> </ex:error-safe> </xsl:template> 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()"/> <ex:error-safe> <ex:try> <xsl:sequence select="error()"/> </ex:try> <ex:catch> <xsl:sequence select="'alternative value'"/> </ex:catch> </ex:error-safe> </xsl:variable> Second example, when the try sequence ctor could throw two errors: <xsl:template match="/"> <ex:error-safe> <ex:try> <xsl:sequence select="error(QName('my:ERR001'), '')"/> <xsl:sequence select="error(QName('my:ERR002'), '')"/> </ex:try> <ex:catch> Error: <xsl:value-of select="ex:current-error()"/> </ex:catch> </ex:error-safe> </xsl:template> 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 now. Thank you for your feedback. Regards, --drkm _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] saxon:try(), Colin Paul Adams | Thread | Re: [xsl] saxon:try(), Colin Adams |
RE: [xsl] document() function and e, Wendell Piez | Date | [xsl] newbie xsl apply-templates ne, John Saylor |
Month |