17191 2012-05-25 17:27:33 +0000 [XQ30] (Too?) magic try/catch syntax 2012-06-26 13:30:48 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.0 Working drafts All All RESOLVED LATER P2 normal --- 1 hannesbauer jonathan.robie jim.melton mike public-qt-comments oldest_to_newest 68145 0 hannesbauer 2012-05-25 17:27:33 +0000 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 68186 1 mike 2012-05-27 11:34:45 +0000 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) 68280 2 hannesbauer 2012-05-29 18:57:33 +0000 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 68282 3 jonathan.robie 2012-05-29 21:32:35 +0000 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. 69243 4 jonathan.robie 2012-06-19 16:41:09 +0000 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. 69245 5 g 2012-06-19 16:47:51 +0000 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. 69411 6 hannesbauer 2012-06-26 13:30:48 +0000 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).