This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm wondering if it's still possible to change the current try/catch syntax of XQuery 3.0? Frankly, with all variables being magically assigned (afaik, something that happens nowhere else in XQuery), it's pretty inconvenient to pass on all error information to another function.. Current solution: try { 123+'456' } catch * { local:handle-error($err:code, $err:description, $err:value, $err:module, $err:line-number, $err:column-number } } Thus it would be great if a) the error could be bound to a specific variable, and/or b) all information could be represented as a single element Resulting queries could look as follows: Query: declare function local:handle($error) { $error }; try { 123+'456' } catch *($e) { local:handle($e) } Result (brave proposal): <XPTY0004 xmlns="http://www.w3.org/2005/xqt-errors" line="4" column="5"> Typing error: ... </XPTY0004> As I'm probably throwing this in pretty late, maybe it is possible to extend the existing draft without endangering the existing functionality; e.g. by making the variable declaration optional, and adding yet another variable ($err:element?) that includes the values of most of the existing variables? It's nice, however, that multiple error codes can be listed in one catch expression. Thanks for your attention, HB
This sounds like a good use case for maps, but sadly it seems maps aren't going to make it into XQuery 3.0. However, it wouldn't be impossible to add it later, with another variable $err:info that holds all the error information in the form of a map. (personal response)
Dear Michael Kay, yes! I would like to see maps included in the specification soon; as far as I can judge, they would also be helpful new functions such as fn:serialize(). Back to try/catch: honestly, the current try/catch solution feels like a short term tradeoff to me (but I must confess I'm no XQuery expert either). Do you think there's any chance that the current solution will be revised in time? What about introducing error variables in a future version of XQuery, as soon as there are maps available, too? Thanks, HB
Maps will not be available in XQuery 3.0. That means that we can't use a map-based solution in this timeframe. XQuery 3.0 needs a way to report errors now. And we do have a solution that works.
The WG has decided not to fix this in XQuery 3.0 In a later version of XQuery, when we have maps, we could add a variable that is bound to a map containing information about the error. I will create a corresponding bug in XQuery 3.1.
If this helps: I am afraid that some of the variables (err:value, err:additional) have type item()* (in theory, these could even be functions), which makes it impossible to embed them into an element. This is why using maps was considered.
Hi Ghislain, thanks for the clarification. So let's just hope that XQuery 3.1 will be available soon (after all, more and more implementations seem to already offer their own maps implementations).