W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2010

[Bug 11547] New: [XQuery3] Scope of try-catch.

From: <bugzilla@jessica.w3.org>
Date: Tue, 14 Dec 2010 12:36:34 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-11547-523@http.www.w3.org/Bugs/Public/>

           Summary: [XQuery3] Scope of try-catch.
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3.0
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: oliver@cbcl.co.uk
         QAContact: public-qt-comments@w3.org
             Group: XSLXQuery_WG

In discussion of bug 10848 at the Lyon Face to Face, another issue was noticed
with the try-catch expression.

The Try/Catch expression (3.13) contains the following text:

A try/catch expression catches dynamic errors and type errors raised during
dynamic evaluation for expressions that are lexically contained within the try

For type errors this is (probably) the correct constraint.

The phrase "lexically contained" is too specific for dynamic errors.  At the
F2F we thought that the intention was that the following error would never be
caught by the try catch:

let $x := 1/0
try { $x } catch { 42 }

but the way the text was worded this would mean that it is not allowed to catch
the following error (as the body of the function is not lexically contained by
the try).  This is presumably a bug

declare function f() { 1/0 };
try { f() } catch { 42 }

We could not come to an agreement as to whether the following error should be

declare variable $x := 1/0;
try { $x } catch { 42 }

I believe that a global variable should behave like a let expression, but the
current text in the specification can be inferred to state that the variable
reference is bound to an error in this case, effectively treating global
variables like monodic functions.

The description of try catch contains the following text that was probably
intended to clarify this:

If a function call occurs within a try clause, errors raised by 
evaluating the corresponding function are caught by the try/catch 
expression. If a variable reference is used in a try clause, errors 
raised by binding a value to the variable are not caught unless the 
binding expression occurs within the try clause.

However the term "binding expression" is never defined, and the term "binding"
only refers to let expressions.  Similarly section 4.16 uses the term
"initializer" which is not defined.

Jim concluded that in order to discuss this further we would require John or
Jonathan to clarify the intention.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 14 December 2010 12:36:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:33 UTC