Re: [XSLT21Req] - catching errors

Sorry for the delay in acknowledging this posting.

What we normally do with postings on public-qt-comments is to transfer 
them to the bugzilla database so that we can track them through to 
completion. It's best if you can enter the comment in bugzilla in the 
first place, because that way you get to follow the discussion. I'm 
happy to transfer this to bugzilla if you want. However, it looks to me 
as if you didn't notice the try/catch facilities in the specification: see

http://www.w3.org/XML/Group/qtspecs/specifications/xslt-21/html/Overview-diff.html#try-catch

Since you obviously have thought about the requirements in this area, it 
would be very useful feedback for the working group if you could review 
the facilities we are proposing, and comment on the extent to which they 
will meet the requirements you discuss in your comments.

We did consider whether to do try/catch at the XPath level, the XSLT 
level, or both, and came to the conclusion that the requirements were 
best met by doing it at the XSLT level.

Best regards,

Michael Kay
(XSLT 2.1 editor)

On 17/06/2010 20:54, Jacques R. Durand wrote:
> 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 <mailto:jdurand@us.fujitsu.com>