3
Vote

Deleting a variable in strict mode produces a SyntaxError, not a ReferenceError (tests 11.4.1-5-1-s, 11.4.1-5-2-s, 11.4.1-5-3-s)

description

The tests 11.4.1-5-1-s, 11.4.1-5-2-s and 11.4.1-5-3-s all assume that deleting a variable in strict mode produces a ReferenceError exception. Section 11.4.1 of the specification contradicts this as it specifies a SyntaxError should be thrown instead.

comments

paulbartrum wrote Oct 6, 2010 at 12:50 AM

I should also note that SyntaxErrors are early errors and thus cannot be caught without using eval().

wrote Dec 7, 2010 at 5:05 PM

jwalden wrote Jan 1, 2011 at 10:44 PM

http://es5conform.codeplex.com/workitem/29141 has a patch that fixes many test suite issues but doesn't address this, because there's a somewhat colorable case that this is not necessarily an early error, and I haven't taken it to es5-discuss yet. But it's worth noting here that SpiderMonkey and (soon, I believe) Nitro will implement this as an early error, even if perhaps that shouldn't play into the calculation of whether these tests should or shouldn't change.

paulbartrum wrote Jan 2, 2011 at 6:20 AM

For the record, my reasoning for believing it is an early error is as follows:
  • Section 11.4.1 step 5 indicates that deleting a variable in strict mode is a SyntaxError.
  • Section 16 says an implementation must treat any syntax error as an early error.
    Seems pretty straightforward to me.

jwalden wrote Jan 3, 2011 at 9:12 PM

The colorable case involves a host object with a [[HasProperty]] hook that has side effects or may throw an exception other than a SyntaxError, then supplied as the object for a with clause, thus making the SyntaxError for deleting a name potentially not reachable if the delete expression is reached at runtime. ES6's proposed proxy specification would enable creation of such an object. The spec says, "An early error is an error that can be detected and reported prior to the evaluation of any construct in the Program containing the error." "can be detected and reported prior to..." is arguably under-defined enough to permit the host object snafu. As I said, I don't like this case, and I think it worth killing. But there is a case that deleting a name is not an early error.

jwalden wrote Jan 3, 2011 at 10:29 PM

wrote Feb 13, 2011 at 7:26 PM

wrote Feb 13, 2013 at 3:09 AM