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

[Bug 9252] New: [XQuery 1.1] Error handling in switch expression

From: <bugzilla@wiggum.w3.org>
Date: Tue, 16 Mar 2010 11:00:56 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-9252-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9252

           Summary: [XQuery 1.1] Error handling in switch expression
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 1.1
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


The current draft says:

[1] A special rule applies to propagation of dynamic errors by switch
expressions. 
[2] The case clauses of a switch expression do not raise any dynamic errors
except in the effective case. 
[3] Dynamic errors raised in the operand expressions of the switch or the case
clauses are propagated. 
[4] An implementation must not raise errors in the operand expressions of case
clauses that occur after the effective case.

Some comments:

(a) it's not entirely clear exactly what it means by "operand expressions" and
"case clauses", though one can make reasonable guesses

(b) In sentence [1], I think the significance of "special" is that this rule
overrides the general provisions in "Errors and Optimization". Perhaps this
should be spelled out.

(c) In [2], I think "case clause" is probably referring to the return
expression and not the operand expressions, but this is not made clear.

(d) Rule [4] is stating an exception to rule [3]. Reading rule [3] on its own
suggests that an error in any operand expression should be propagated, whether
or not it comes after the effective case.

(e) Stylistically, it's odd that the subject of the four sentences is in each
case a different kind of thing: respectively "a rule", "a case clause", "an
error", and "an implementation".

(f) None of this applies to static errors or type errors, and this should
perhaps be explicitly stated. In [1..3] the rule does say that it refers only
to "dynamic errors", but there is no such qualification in rule [4]; a reader
might infer that type errors in cases after the effective case are not to be
reported. This does raise a question about when type errors could/should/must
be reported, for example in

switch ($x)
case "string" return "a"
case 42 return "b"
default return "c"


-- 
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, 16 March 2010 11:00:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:59 GMT