Evaluating a query has two phases: the analysis phase, which catches static errors, and the evaluation phase, which catches dynamic errors. This section does not cover static errors, since they can be caught by the query processor and debugged as part of the development process. The dynamic errors are the unexpected errors that need to be considered carefully when writing queries.
Some programming languages have a try/catch feature that allows the processor to try to perform a series of instructions (specified in the "try" clause), but if there is an error, gracefully bow out and perform another series of instructions (specified in the "catch" clause). There is no concept of try/catch in XQuery, so it is up to the query author to anticipate the kinds of errors the processor will raise and avoid evaluating those expressions.
It is important to consider variations in the input documents that may cause dynamic errors. For example, if you are dividing a total amount by the number of items in an order, consider the possibility that there are no items in the order, which may result in a "division by zero" error. You can avoid this by checking the number of items first, as in:
if ($items) then $orderTotal div count($items) else 0
Dynamic type errors often occur when data cannot be cast to the required type. For example, to double the price discount, you might use the expression 2 * $discount. This expression raises a dynamic error if the value of discount is N/A or a zero-length string, which cannot be cast to a numeric type. You can avoid a dynamic error by checking whether a value is castable in advance, as in:
if ($discount castable as xs:decimal) then 2 * $discount else 0
If the input data is really in error (and you are not performing schema validation), it may be helpful to test for the error condition and raise a more meaningful error using the error function. If the input data is not in error, you should modify the query to allow for the variations in input documents.
If an input document is schema validated, you can be less concerned about some of these dynamic errors. For example, if the schema specifies that the number of items in an order must be more than zero, you may not have to worry about a "division by zero" error. If the schema validates that the type of a discount element is xs:decimal, there is no chance that it is N/A.
The error function is used to explicitly raise an error when certain conditions arise. For example, if an important data item is missing or invalid, you may want to stop evaluation of the query with a specific error message. To do this, you can incorporate calls to the error function in your query. For example:
if (not($product/number))
then error(QName("http://datypic.com/err", "ProdNumReq"), "missing product number")
else $product/numberraises a ProdNumReq error (whose description is "missing product number") if $product has no number child.
During the query debugging process, the trace function can be used to track the value of an item. For example:
trace($var1, "The value of $var1 is: ")
might write the string The value of $var1 is: 4 to a logfile.