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 29320 - [XQ31] Switch expressions should have same error semantics as typeswitch
Summary: [XQ31] Switch expressions should have same error semantics as typeswitch
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC 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: 2015-12-02 15:08 UTC by Michael Kay
Modified: 2016-01-04 10:25 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2015-12-02 15:08:49 UTC
In section 2.3.4, conditional expressions and typeswitch expressions are given special status with regard to error handling: they "must not raise a dynamic error in respect of subexpressions occurring in a branch that is not selected, and must not return the value delivered by a branch unless that branch is selected".

Section 3.15 on Switch Expressions states that switch expressions also have this protection: "Switch expressions have rules regarding the propagation of dynamic errors that take precedence over the general rules given in 2.3.4 Errors and Optimization. The return clauses of a switch expression must not raise any dynamic errors except in the effective case.

Since 2.3.4 explicitly mentions conditional and typeswitch expressions as having this property, it should also mention switch expressions in the same sentence.

Incidentally, I have no idea what the clause "and must not return the value delivered by a branch unless that branch is selected" is supposed to add.
Comment 1 Michael Dyck 2015-12-02 16:33:04 UTC
(In reply to Michael Kay from comment #0)
> 
> Incidentally, I have no idea what the clause "and must not return the value
> delivered by a branch unless that branch is selected" is supposed to add.

That wording was added via erratum XQ.E4:
    http://www.w3.org/XML/2007/qt-errata/xquery-errata.html#E4)
which refers to Bugzilla Bug 4446:
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=4446
In comment 2, you proposed wording that included the clause you quote above.
There ensues some discussion of that very clause, but I'm not sure it'll answer your question.
Comment 2 Michael Kay 2015-12-02 16:52:05 UTC
Thanks for the detective work! It does reveal what I was thinking when I wrote this. Perhaps the fact that I was unable to decipher the intent 8 years later suggests that clarification is needed.

So the intended meaning is, if one branch of the conditional is a value, and the other branch is an error, then the normal rule that you can return the value without testing the condition doesn't apply.
Comment 3 Michael Kay 2015-12-08 17:13:50 UTC
Looking at this example:

if (condition) then 'z' else error()
Comment 4 Jonathan Robie 2015-12-08 17:16:00 UTC
The solution seems to be to add "switch expressions" to 2.3.4 Errors and Optimization where it currently says "conditional or typeswitch expressions".

Typeswitch adds this:

A special rule applies to propagation of dynamic errors by typeswitch expressions. A typeswitch expression ignores (does not raise) any dynamic errors encountered in case clauses other than the effective case. Dynamic errors encountered in the default clause are raised only if there is no effective case. An implementation is permitted to raise dynamic errors in the operand expressions of case clauses that occur before the effective case, but not required to do so.

Switch adds this:

Switch expressions have rules regarding the propagation of dynamic errors that take precedence over the general rules given in 2.3.4 Errors and Optimization. The return clauses of a switch expression must not raise any dynamic errors except in the effective case. Dynamic errors raised in the operand expressions of the switch or the case clauses are propagated; however, an implementation must not raise dynamic errors in the operand expressions of case clauses that occur after the effective case. An implementation is permitted to raise dynamic errors in the operand expressions of case clauses that occur before the effective case, but not required to do so.

Conditional expressions add this:

Conditional expressions have a special rule for propagating dynamic errors. If the effective value of the test expression is true, the conditional expression ignores (does not raise) any dynamic errors encountered in the else-expression. In this case, since the else-expression can have no observable effect, it need not be evaluated. Similarly, if the effective value of the test expression is false, the conditional expression ignores any dynamic errors encountered in the then-expression, and the then-expression need not be evaluated.
Comment 5 Michael Kay 2015-12-08 17:18:57 UTC
they "(a) must not raise a dynamic error in respect of subexpressions occurring in a branch that is not selected, and (b) must not return the value delivered by a branch unless that branch is selected"

Note; the effect of (b) is that given an expression such as "if (condition) then 'x' else error()", the implementation is not allowed to return 'x' without first checking that condition is true.
Comment 6 Andrew Coleman 2016-01-04 10:25:00 UTC
This has been fixed in the editors' draft as agreed at the teleconference on 2015-12-08.

See https://lists.w3.org/Archives/Public/public-xsl-query/2015Dec/0022.html