Yesterday, incidentally, I've arrived to a problem of a dynamic error during evaluation of a template's match. This reminded me SFINAE in C++. There the principle is applied at compile time to find a matching template.
I think people underestimate the meaning of this behaviour. The effect of dynamic errors occurring during pattern evaluation is described in the specification:
Any dynamic error or type error that occurs during the evaluation of a pattern against a particular node is treated as a recoverable error even if the error would not be recoverable under other circumstances. The optional recovery action is to treat the pattern as not matching that node.
This has far reaching consequences, like an error recovery. To illustrate what I'm talking about please look at this simple stylesheet that recovers from "Division by zero.":
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xsl:template match="/"> <xsl:variable name="operator" as="element()+"> <div divident="10" divisor="0"/> <div divident="10" divisor="2"/> </xsl:variable> <xsl:apply-templates select="$operator"/> </xsl:template> <xsl:param name="NaN" as="xs:double" select="1.0 div 0"/> <xsl:template match="div[(xs:integer(@divident) div xs:integer(@divisor)) ne $NaN]"> <xsl:message select="xs:integer(@divident) div xs:integer(@divisor)"/> </xsl:template> <xsl:template match="div"> <xsl:message select="'Division by zero.'"/> </xsl:template> </xsl:stylesheet>
Here, if there is a division by zero a template is not matched and other template is selected, thus second template serves as an error handler for the first one. Definitely, one may define much more complex construction to be handled this way.
I never was a purist (meaning doing everything in xslt), however this example along with indirect function call, shows that xslt is rather equiped language. One just need to be smart enough to understand how to do a things.
See also: Try/catch block in xslt 2.0 for Saxon 9.