- From: Jacques R. Durand <JDurand@us.fujitsu.com>
- Date: Thu, 17 Jun 2010 12:54:19 -0700
- To: <public-qt-comments@w3.org>
- Message-ID: <0D4373E9E1236F42AB63FD6B5B306AA301733578@SV-EXCHANGE.fjcs.net>
Missing: A standard and convenient exception (or error) handling mechanism That would help a lot write reliable transforms on par with what you get with conventional programming languages, the failure outcome of which should not depend so much on implementations. In many cases "non-recoverability" is a relative - or local - concept: just because an XPath expression cannot recover from a dynamic error, does not mean that my entire transform should fail. E.g., many times I have had expressions failing because an XPath function was expecting a node argument, while a sequence was actually produced, something I wish I could recover from instead of preventing it by altering the argument expression to "hide" unexpected conditions in the input, which I'd like to remain aware of. I can see two levels of error catching: (a) inside expressions, using a new function of the kind: fn:on-error( <error code>, <primary-expression>, <alternate-expression>) could help fine-grain error handling. (b) at template level in the markup, a new <xsl:error-handling> element could wrap any bloc of xsl statements, and contain <xsl:on-error code="(error code)">...</xsl:on-error> child elements that define the error catching xsl code. Thanks, Jacques Durand Fujitsu jdurand@us.fujitsu.com
Received on Thursday, 17 June 2010 19:55:12 UTC