- From: <bugzilla@jessica.w3.org>
- Date: Thu, 22 May 2014 11:12:39 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25174 --- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> --- Re comment 2: I thought of it, but I think we run into even more trouble, consider: <xsl:try> <xsl:stream href="good.uri"> <xsl:apply-templates select="x" /> </xsl:stream> <xsl:catch ="err:Special"> <xsl:message select="'Rolled back'" /> </xsl:catch> </xsl:try> <xsl:template match="x"> <xsl:try> <xsl:value-of select="@y mod @z" /> <xsl:stream href="{@baduri}"> <xsl:apply-templates /> </xsl:stream> <xsl:catch select="*"> <xsl:message select="'What is rolled back?'" /> </xsl:catch> </xsl:try> </xsl:template> The second try/catch must somehow differentiate between 1) buffering and rollback current context in case of div by zero 2) poking @baduri for I/O and rolling back without applying templates 3) buffering apply templates and rolling back 4) if halfway streaming getting I/O error, rolling back apply templates Even though implementations might be able to do this, I don't think it is good to have one construct follow different semantics by one the same syntax and different rollback behavior with potentially the same (I/O) error. Which is why I presently prefer the (slightly) different syntax (xsl:catch as child of xsl:stream) where the position and focus of xsl:catch makes it unambiguous what is going on and what is going to be caught and/or rolled back. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 22 May 2014 11:12:41 UTC