This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17191 - [XQ30] (Too?) magic try/catch syntax
Summary: [XQ30] (Too?) magic try/catch syntax
Status: RESOLVED LATER
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Working drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-25 17:27 UTC by HB
Modified: 2012-06-26 13:30 UTC (History)
2 users (show)

See Also:


Attachments

Description HB 2012-05-25 17:27:33 UTC
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
Comment 1 Michael Kay 2012-05-27 11:34:45 UTC
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)
Comment 2 HB 2012-05-29 18:57:33 UTC
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
Comment 3 Jonathan Robie 2012-05-29 21:32:35 UTC
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.
Comment 4 Jonathan Robie 2012-06-19 16:41:09 UTC
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.
Comment 5 Ghislain Fourny 2012-06-19 16:47:51 UTC
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.
Comment 6 HB 2012-06-26 13:30:48 UTC
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).