- From: <bugzilla@jessica.w3.org>
- Date: Fri, 14 Sep 2012 11:34:52 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18877 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 expressions (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 evaluated. -- 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