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

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

--- Comment #18 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to Michael Kay from comment #17)
> The constructor function xs:error($x) is actually equivalent to "cast $x as
> xs:error?", not to "cast $x as xs:error".

Then the text is wrong too, isn't it?  Shouldn't cast( () ) return the empty
sequence, without raising an 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.

Nice.

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

Thanks.

> 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.

Yes, that's the best use case I've heard.

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

Received on Thursday, 8 October 2015 20:18:45 UTC