W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2012

[Bug 18877] [XQ30] try/catch

From: <bugzilla@jessica.w3.org>
Date: Fri, 14 Sep 2012 11:34:52 +0000
Message-Id: <E1TCUAe-0003WJ-UL@jessica.w3.org>
To: public-qt-comments@w3.org

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> 2012-09-14 11:34:52 UTC ---
Yes, I've always felt the spec was too informal in this area. And I also don't
think it's too hard to get right.

Basically, we should say that the evaluation of an expression E may directly
cause the evaluation of another expression F. This relationship has a
transitive closure, "directly or indirectly causes", and we can say that an
error in the evaluation of an expression Z is caught by a try/catch expression
T if evaluation of the "try" block of T directly or indirectly causes the
evaluation of Z. We can then enumerate how one expression may directly cause
the evaluation of others:

(a) evaluation of an expression directly causes the evaluation of its operand

(b) evaluation of a function call directly causes the evaluation of the
corresponding function body 

[(c) evaluation of a variable reference does NOT directly cause the evaluation
of the variable initializer]

and that's about it. We can use this rhetoric to more formally explain the case
where an exception is not caught by an outer try/catch because it is caught by
an inner try/catch.

Putting this machinery into place would help greatly in the XSLT spec, where we
need to explain for example whether an error in evaluating a match pattern is
caught by the apply-templates instruction that caused the pattern to be

Configure bugmail: https://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 Friday, 14 September 2012 11:34:58 UTC

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