W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2010


From: Jacques R. Durand <JDurand@us.fujitsu.com>
Date: Thu, 17 Jun 2010 12:54:19 -0700
Message-ID: <0D4373E9E1236F42AB63FD6B5B306AA301733578@SV-EXCHANGE.fjcs.net>
To: <public-qt-comments@w3.org>
Missing: A standard and convenient exception (or error) handling
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.
Jacques Durand
Received on Thursday, 17 June 2010 19:55:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:31 UTC