Error Handling

There are two kinds of error that can occur during an XSLT transformation: static errors and dynamic errors. Static errors occur while the stylesheet is being compiled, and dynamic errors occur while the transformation is actually running. If you invoke the transformation using a "single-shot" interface that doesn't distinguish compilation from execution then you may not notice the difference, but it is there all the same.

XSLT 1.0 was designed to minimize the number of things that could cause runtime errors. This was done largely by defining fallback behavior. For example, if you supplied the string "Africa" as input to an arithmetic operator, you would get the result NaN ( not-a-number ). This might not be a very useful result, but the thinking was that it was better than producing a pop-up on the browser saying "Error in stylesheet". For many runtime errors, implementors were in fact given a choice of reporting an error, or taking some defined fallback action.

The thinking in XSLT 2.0 has shifted significantly. There are now many more conditions that cause runtime errors, and many of these are not recoverable. There is also no try/catch mechanism to trap the errors when they occur: if a runtime error does occur in a stylesheet, it is fatal. In practice this means that you have to design your stylesheet to prevent them occurring. This means that you have to test whether the input data is valid before using it in an operation that could cause errors if it isn't valid. For example, before trying to convert a string to an integer using the xs:integer() constructor function, it is a good idea to test whether the conversion is possible using a construct such as «if ($x castable as xs:integer) then ... » .

Although the language specification is very precise about what constitutes an error and what doesn't, there may well be variations between processors as to whether runtime errors are actually reported in particular circumstances. This is partly because the choice of reporting the error or taking fallback action is still there, as in XSLT 1.0; and it is also because the order of execution of instructions (or of subexpressions within an XPath expression) is not precisely defined. Suppose you write an expression such as «exists ( / /employee [@retirement-date = current-date ()]) » (which finds out whether any employees are retiring today). One XSLT processor might find such an employee, and return true . Another might find an employee whose retirement-date attribute is not a date (perhaps it is the string "unknown" ) and report a runtime error. Processors are never required to do extra work just to look for runtime errors. In this example, the processor is allowed to stop searching the employees as soon as it finds one that satisfies the required conditions.

What if there are no employees retiring today, and there are some employees whose retirement dates are not valid dates? Does the processor have to raise a runtime error, or can it return false ? A straightforward reading of the specification suggests that it has to report an error in this case. However, the rules that allow the processor to devise an optimal execution strategy are drawn up so broadly that I think an implementor could argue that returning false was conformant behavior.