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

[Bug 11171] [XQuery11] dynamic errors reported during static analysis

From: <bugzilla@jessica.w3.org>
Date: Fri, 29 Oct 2010 23:35:23 +0000
To: public-qt-comments@w3.org
Message-Id: <E1PByTj-00084Q-PL@jessica.w3.org>

--- Comment #2 from Michael Dyck <jmdyck@ibiblio.org> 2010-10-29 23:35:23 UTC ---
(In reply to comment #0)
> I suggest that we should change this to consider only the evaluation of
> the QueryBody. Our spec would now say:
> "Independently of whether the Static Typing Feature is in effect, if an
> implementation can determine during the static analysis phase that the
> evaluation of the QueryBody would necessarily raise a type error or a
> dynamic error, the implementation may (but is not required to) report
> that error during the static analysis phase.

So, e.g., if the QueryBody were

    if ($condition) then 1 + "red" else "foo"

static analysis would not be allowed to raise a type error (for 1 + "red")
unless it either:
a) could prove that $condition was always true, or
b) implemented the Static Typing feature.


It occurs to me that the phrase "evaluation would necessarily raise an error"
is somewhat ambiguous when there's more than one possible evaluation (i.e.,
when evaluation depends on not-statically-known factors such as the content of
documents or the value of external variables). It could mean:
    there exists an error such that all possible evaluations
    would raise that error
    each possible evaluation would raise an error,
    but different evaluations may raise different errors.
The subsequent phrase "report that error" suggests the first interpretation,
but I wonder if we're okay with the second interpretation. (This ambiguity
exists in both the existing wording and the proposed new wording.)

> However, the fn:error() function must not be evaluated during the static
> analysis phase."

With the change to QueryBody, that sentence would perhaps be unwanted. I.e., if
static analysis can prove that running the query would necessarily raise an
error, then I imagine the user would like the error reported statically,
regardless of whether it arises from a call to fn:error().

> Section 3.11 Conditional Expressions has special rules for propagating dynamic
> errors:

(and 3.15.2 has special rules for Typeswitch Expressions)

> We should add similar wording to 3.14 Try/Catch Expressions:

I'm not sure that these rules really are "special". They seem to boil down to
"Don't raise errors from evaluations that the spec doesn't tell you to do."

Do we similarly need "special rules" to say that implementations must not raise
a dynamic error in cases such as:
    for $i in () return $i/0
    some $i in () satisfies $i/0 > 2
    (1,2)[false][. div 0]

> I believe that with these rules, the following query would not be allowed to
> raise an error.
>    declare variable $v := 1 div 0;
>    declare function local:f () { 1 div 0};
>    "No problem here!"

Well, the shift to QueryBody would mean that no error could be reported during
static analysis. However, I'm pretty sure an implementation would be allowed to
raise a divide-by-zero error during dynamic evaluation, because there's no rule
to say that you mustn't evaluate the initializer of an unused variable. (In
fact, the wording in 4.16 seems to say that you must, but I imagine people will
claim that 2.3.4 says you needn't.)

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 Friday, 29 October 2010 23:35:25 UTC

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