- From: <bugzilla@jessica.w3.org>
- Date: Tue, 14 Dec 2010 12:36:46 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10848 Oliver Hallam <oliver@cbcl.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #7 from Oliver Hallam <oliver@cbcl.co.uk> 2010-12-14 12:36:45 UTC --- I have reviewed the minutes from the F2F meeting. I believe that at the end of the first day we decided the bug was resolved, but after further discussion on the second day we concluded that this solution still left some open issues, and more discussion was required in order to fully resolve this. I do not think we came to a satisfactory decision. Whilst the original decision in the minutes was to close the bug, this was later retracted, and the item in the minutes was left pending. Here is a brief summary of the discussion: There are three classes of errors: dynamic errors, static errors and type errors. Static errors (eg parse errors) should not be caught by the try-catch expression. Dynamic errors should be caught by the try-catch expression (although if they can be detected statically then the implementation is still free to optimize the the try-catch to its catch expression, etc). Type errors are slightly more problematic - Some members wanted to break them down into static type errors and dynamic type errors and apply the rules above. Other members (including me) did not believe that there is a sufficient distinction between a static type error and a type error detected statically. Thus I belive the intention was just to specify that a type error detected statically MAY be raised statically, but if it is detected dynamically MUST be caught by the try-catch. In order to achieve these goals we believed the following change was sufficient: Independently of whether the Static Typing Feature is in effect, if an implementation can determine during the static analysis phase that a query body, if evaluated, would necessarily raise a dynamic error or an expression, if evaluated, would necessarily raise a type error, the implementation may (but is not required to) report that error during the static analysis phase. Unfortunately this does not actually solve the original reported problem!. That is, the wording for the try catch expression still says "If an error found in a try clause can be detected statically, an implementation is free to raise a static error", which is not correct. In order to remain consistent with our this should only refer to static errors, or type errors detected statically, and not to dynamic errors detected statically. Whilst we had clarified what class of errors are caught by the try-catch expression, there were some questions as to the scope of the effect. I have opened a seperate bug (#11547) to track this issue. -- 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:47 UTC