[Bug 29119] [XP31] xs:error always raises a type error

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29119

--- Comment #17 from Michael Kay <mike@saxonica.com> ---
The constructor function xs:error($x) is actually equivalent to "cast $x as
xs:error?", not to "cast $x as xs:error".

For function calls, I would say:

declare function local:f($arg as xs:error) {...} is a valid function
declaration, but a function call local:f($x) will always fail (statically or
dynamically) with a type error XPTY0004.

Note: in all the above examples, it is assumed that evaluation of $x does not
fail. In some cases, the "Errors and Optimization" rules ensure that $x does
not need to be evaluated (because the result does not depend on its value),
which means that errors in evaluating $x may be masked.

Note to editor: some of these examples apply to both XPath and XQuery, some are
XQuery-only.

During the call Tim suggested (to me) an interesting use case. Suppose we have
a function

process-invalid-chars($x as xs:string, $f as function($s as xs:string) as
xs:error)) as xs:string

which processes the supplied string $x by calling the supplied function $f to
handle any character that is deemed invalid.

$f acts here as a kind of error handler. It cannot return a result, because no
result will ever satisfy the required return type xs:error; so it is
constrained to throw a dynamic error. But it can choose what dynamic error to
throw.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 6 October 2015 22:40:59 UTC